Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How about trailing commas in SQL?

peter.eisentraut.org

Post reply on HN
Print view View original

231–240 of 272 posts

Re: How about trailing commas in SQL?

#231

Post by adrian_b »

cnity wrote: post #127
Quekid5 wrote: post #56

Earlier quoted context omitted.

> Code ligature thing has something to do with just seeing the characters that are actually there rather than a smokescreen, which IMO impedes editability because I can't place the cursor half-way through a ligature and so on Why wouldn't that be possible? (The cursor thing) It's still two characters as far as your editor is concerned.

I didn't say it's not possible, but certainly when I've tried ligatures in the past my editor treated it like a single character until I pressed backspace after the character (or delete before) or whatever. Anyhow there's all sorts of weird functional artefacts that just feel dodgy to me and they basically all arise from this world where multiple runes are being treated as a single one. Here are two more examples: 1.…

Among the editors which handle well ligatures is Geany.

The cursor moves always over a character, regardless whether it is part of a ligature or not. You can select and delete or replace only a part of a ligature, exactly in the same way as when using a font without ligatures.

The only thing that ligatures change is the visual appearance of the text, which is in my opinion an extremely useful workaround for the inertia of the legacy programming languages, which continue to use the restricted ASCII character set, which has never included all the characters that would have been needed in a programming language.

Now with ligatures, we are finally able to write an ALGOL 60 program that looks like it was intended to look, 65 years ago, instead of being forced to use awkward combinations of ASCII characters, like later programmers and designers of programming languages have resigned themselves to do, because of the character set limitations that the American manufacturers of computing equipment have been unwilling to remove (causing problems not only to programmers, but also to the users of non-English languages).

ASCII has never been intended to include the characters required for writing mathematical expressions. ASCII has been intended only to include the set of characters that were in use in the commercial correspondence written in English, which had been previously available in the better typewriting machines. Because of this, ASCII has always been bad as a character set used for a programming language.

Re: How about trailing commas in SQL?

#232

Post by tete »

masklinn wrote: post #10
nickcw wrote: post #7

I feel like this ship has sailed. SQL has been around for more than 50 years and everyone who needs to generate it has already put that extra `if` statement in to suppress trailing commas. What annoys me far more often is the lack of support for trailing commas in JSON.

Funny I’m the exact opposite: I essentially never write JSON by hand, or add json content to repositories, so could not care less about the lack of trailing commas, I do semi routinely write or review SQL.

I agree. And JSON basically isn't meant to be hand-written, just easy to glance over, if you need to or do basic tests with. It's a serialization format. It's not a config format or anything like that. The idea of wanting to use it for that (when the config needs to be hand-written) should be a red flag for anyone. Why would you want to hand-write something where a key is denoted with double quotes?

And just to be clear: YAML is also not a config format and wasn't meant to be. YAML is for metadata style stuff that is supposed to be close to humans, heck the whole yes/no and "not so strict" typing parts.

If you want a config format you got many options: There is toml/ini and friends on one side and UCL/HCL/... on the other. Or if you want to go really simple, do something like Postgres, Tor, etc. do and just use space separated strings.

Re: How about trailing commas in SQL?

#233

Post by spprashant »

larrik wrote: post #219
spprashant wrote: post #190

Not worth the trouble. This is such a cosmetic change to appease a specific type of developer but the effort to implement that across all the DB engines of note would be monumental.

It's not just cosmetic, though, as now in order to add a new entry at the end you need to change two lines of code, which means your git blame is no longer accurate.

Literally unusable.

Re: How about trailing commas in SQL?

#234

Post by refset »

atombender wrote: post #105
adornKey wrote: post #6

I feel the problem. When coding (not only in SQL) you often have to add something to the end of a list, and it is annoying that the end of the list is always special. You can't just copy some line and move it there. Also when moving things around you always have to take extra care at the end. So, my solution for this was always SELECT a , b , c FROM ... instead of: SELECT a, b, c, -- people want to allow trailing com…

I often do this with boolean WHERE filters when I'm doing interactive exploration on some data: SELECT ... WHERE foo = 1 AND bar = 2 I want to comment out a line (i.e. "--foo = 1"), but would break the syntax. The solution is to start with "WHERE true": SELECT ... WHERE true --AND foo = 1 AND bar = 2 Now you can comment/comment anything. (Putting the AND at end of each line has the same problem, of course, and requir…

In XTDB you can now use (trailing-friendly) commas in this scenario too, instead of ANDs: https://github.com/xtdb/xtdb/pull/3985

Re: How about trailing commas in SQL?

#235

Post by jghn »

Supermancho wrote: post #122
jghn wrote: post #84

Earlier quoted context omitted.

Have written a lot of code over ~35 years. Not a fan of trailing commas in any language I've used.

That seems odd. The number of times you have had to correct for commas is 100% over 0% Now extrapolate to the whole industry. There's a cost, regardless of how someone might want to value it.

I find them aesthetically displeasing and almost never get annoyed by having to twiddle a comma here or there. If I were to stack rank things that hinder my efficiency, they'd be down towards the bottom.

I mean sure, if people spend most of their day just mindlessly copy pasting crap then perhaps I guess. But compared to the amount of time I find I spend thinking about the actual problem at hand, the single keystroke to edit a comma is a rounding error.

Re: How about trailing commas in SQL?

#236

Post by SPBS »

quietbritishjim wrote: post #51
adornKey wrote: post #24

Earlier quoted context omitted.

Adding something to the end is the most common thing to do. And changing the start is extremely rare - it's anyway special because you usually put it in the line with the SELECT.

> you usually put it in the line with the SELECT. No, you usually don't. That would "bury" the first field so you don't immediately see it if you quickly glance at the code. I'll admit I was a bit surprised when I saw a fully formatted SQL query but it does look much better: SELECT a, b, c, d FROM Customers ORDER BY b, c DESC Edit: I've just seen other comments here suggesting you return an extra "pad" value at the s…

I always do this. There's usually one field that you can put at the start that never changes. But the field at the end will keep changing as you add more fields to the SELECT list.

   SELECT
      a
      ,b
      ,c
      ,d
   FROM
      Customers
   ORDER BY
      b
      ,c DESC

Re: How about trailing commas in SQL?

#237

Post by marcosdumay »

roenxi wrote: post #197
marcosdumay wrote: post #186

Earlier quoted context omitted.

You can get either commas or required `as` and parenthesis around expressions. IMO, required `as` and parenthesis are better. But it's not a clear thing where everybody will agree.

Ideally there'd be a syntax that looked like a function `SELECT(a, b, c, d)` with a totally distinct variant for specifying types `TSELECT(a, int, b, null, c, text, d, timezonetz)`. The big problem here is the seemed-good-in-the-70s syntax that died with SQL. In the best of all possible worlds they could have just used Lisp as the foundation then let people macro/transpile their own syntaxes. A subtle flaw in SQL is…

Oh, just add optional commas at the end of your language's parameter lists...

I have really no idea what's "ideal". Haskell's "white space means application" is way nicer than most function syntaxes, end of line statement separation work very well if you don't need any long statement, the SQL complex syntax is very convenient... and yet if you mix any of those things, you'll get a truckload of disastrous issues.

But one thing that is clear is that allowing for trailing commas in SQL is a gain.

Re: How about trailing commas in SQL?

#238

Post by specialist »

rollcat wrote: post #177
specialist wrote: post #166

Earlier quoted context omitted.

This would work (w/ a context free grammar) if aliases required the 'AS' keyword. Ambigious: SELECT a aliasA b c aliasC FROM d aliasD e Unambigious: SELECT a as aliasA b c as aliasC FROM d as aliasD e Alternately, a schema-aware parser could determine if 'aliasA' was an alias or a column reference. FWIW, personally, I'd rather go the full-Python, using newlines as delimiters: SELECT a aliasA b c aliasC FROM d aliasD…

> FWIW, personally, I'd rather go the full-Python, using newlines as delimiters: I love Python - mostly, but significant whitespace is its worst curse, and I'd love new languages to move away from the idea. I enjoy Rust because I can write out garbage faster than I can think of it, and the auto-formatter will make it look neat. Also, have you experienced the unspeakable horror that is templating YAML files? Of course…

Aside: I avoid ORM hell by using SQL to generate source code.

Re: How about trailing commas in SQL?

#239

Post by essentia0 »

trailingcoma wrote: post #200
Supermancho wrote: post #122

Earlier quoted context omitted.

That seems odd. The number of times you have had to correct for commas is 100% over 0% Now extrapolate to the whole industry. There's a cost, regardless of how someone might want to value it.

Lmao yeah, web pages take 10+ seconds to load megabytes of JavaScript that do nothing but waste time and energy, but the SQL commas are the real culprits! What a joke.

a joke worth making a burner over?

Re: How about trailing commas in SQL?

#240

Post by chihuahua »

cnity wrote: post #13
adornKey wrote: post #6

I feel the problem. When coding (not only in SQL) you often have to add something to the end of a list, and it is annoying that the end of the list is always special. You can't just copy some line and move it there. Also when moving things around you always have to take extra care at the end. So, my solution for this was always SELECT a , b , c FROM ... instead of: SELECT a, b, c, -- people want to allow trailing com…

> it is annoying that the end of the list is always special. You can't just copy some line and move it there. Also when moving things around you always have to take extra care at the end. You have simply moved the "special" entry to the beginning rather than the end. Side remark: I've noticed that when it comes to code formatting and grammar it's almost like there are broadly two camps. There are some instances of co…

I'm not sure if this is an example of code ligatures, but I used to work with a guy who had configured his editor so that "=>" was replaced with some kind of special arrow character, and it used to drive me nuts. When I read code, I want to know what's actually there, and not have to ask "what does that arrow actually mean?"
Post reply on HN