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

21–30 of 272 posts

Re: How about trailing commas in SQL?

#21

Post by masklinn »

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…

That is the haskell workaround, and it also sucks, because it still requires a special non-uniform first value.

I do not want to write either of your snippets, I want to write

  SELECT
      a,
      b,
      c,
  FROM
Because now selected values are uniform and I can move them around or add new ones with minimal changes no matter their position in the sequence.

It’s also completely wonky in many contexts e.g. CREATE TABLE. Trailing commas always works.

> I'd suggest to maybe just change your coding style - and make the start of the list special - instead of the end.

Supporting trailing commas means neither is special.

Re: How about trailing commas in SQL?

#22

Post by tmpfs »

I suspect that it's perfectly valid to name a column "from" or any other SQL keyword so allowing a trailing comma would make the grammar ambiguous.

Personally I agree with the sentiment, I find it annoying to have to juggle the commas on the last column name but I think there is likely a valid reason to do with making lexing easier to reason about.

Re: How about trailing commas in SQL?

#23

Post by croes »

robertlagrant wrote: post #4
elric wrote: post #2

Ugh. Why? To make copy/paste programming easier? To make query generation easier? When you're writing code to generate queries, it's worth doing it right. Just about every programming language has an easy way to take an array of strings and add a separator between each element. Like PHP's implode: implode(', ', ['foo', 'bar', 'baz']) == 'foo, bar, baz'. Every time I see a trailing comma, I think "is this a bug? did t…

It's so you can do this in code: my_things = [ "thing_1", "thing_2", "thing_3", ] And not have to juggle commas when you add a new end thing.

That’s why I use leading commas.

Re: How about trailing commas in SQL?

#24

Post by adornKey »

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…

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.

Re: How about trailing commas in SQL?

#25

Post by tezza »

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 do this as well.

on top i often do a pad entry so that the elements are all on their own line

  SELECT 1 as pad
    , a
    , b
then i can reorder lines trivially without stopping to re-comma the endpoints or maintain which special entry is on the line of the SELECT token

what would be helpful is both LEADING and trailing commas

so I am suggesting:

  SELECT
    , a
    , b
would be permissible too. The parsing step is no longer the difficult portion.

Developer ease leads to less mistakes is my conjecture.

Re: How about trailing commas in SQL?

#26

Post by DonHopkins »

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…

That's as bad as using regular expressions: now you have TWO problems.

Why do you seem to think you've cleverly solved the problem, when you've just moved the problem somewhere else just as bad, by blithely messing with the standard formatting conventions universally used by most human written languages and programming languages in the world?

Programming languages borrow commas from human written languages, and no human written languages have leading commas. And moving the problem to the beginning on the list because you sometimes add things to the end ignores the fact that that also causes problems with READING the code as well as writing it, and you READ code much more often than you WRITE it.

That's not a solution at all, and there's nothing clever about it. You've just pushed the problem to the beginning of the list, and now your code is also butt-ugly with totally non-standard formatting, which sane people don't recognize and editors and IDEs and linters don't support.

I agree with cnity that it's too clever by half, and I'm in the camp (along with Guido van Rossum and his point that "Language Design Is Not Just Solving Puzzles" [1] [2]) that's not impressed by showboating displays of pointlessly creative cleverness and Rube-Goldbergeesque hacks that makes things even worse.

Of course it's not as bad as tezza's clever by a third suggestion to add a confusing throw-away verbose noisy arbitrarily named pad element at the beginning, that actually forces the SQL database to do more work and send more useless data. Now you have three or more problems. The last thing we need is MORE CODE and network traffic contributing to complexity and climate change. I would fire and forget any developer who tried to pull that stunt.

[1] https://www.artima.com/weblogs/viewpost.jsp?thread=147358

All Things Pythonic: Language Design Is Not Just Solving Puzzles. By Guido van van Rossum, February 10, 2006.

Summary: An incident on python-dev today made me appreciate (again) that there's more to language design than puzzle-solving. A ramble on the nature of Pythonicity, culminating in a comparison of language design to user interface design.

[...] The unspoken, right brain constraint here is that the complexity introduced by a solution to a design problem must be somehow proportional to the problem's importance. In my mind, the inability of lambda to contain a print statement or a while-loop etc. is only a minor flaw; after all instead of a lambda you can just use a named function nested in the current scope.

[...] And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable.

[2] http://lambda-the-ultimate.org/node/1298

The discussion is about multi-statement lambdas, but I don't want to discuss this specific issue. What's more interesting is the discussion of language as a user interface (an interface to what, you might ask), the underlying assumption that languages have character (e.g., Pythonicity), and the integrated view of semantics and syntax of language constructs when thinking about language usability.

Re: How about trailing commas in SQL?

#27

Post by citrin_ru »

f4c39012 wrote: post #18

I guess trailing commas would make constructing the clauses programatically a little easier, if they are being appended one-by-one. On the downside, does this make it easier to write code that is vulnerable to command injection, because it is easier to append a bunch of statements passed as input? For the WHERE clause, if i happen to be programatically appending conditions, i'll start with `WHERE true` so i don't nee…

Programmatically it is easy to not add trailing comma (just use something like `join(',', array)`) but it would save time during manual editing of a long query - I often add a new line then run query to discover that I forgot to add , on a previous line. When each line including the last one ends with , I can just add a new line (also ending with ,) and save time.

Re: How about trailing commas in SQL?

#28

Post by dmurray »

tmpfs wrote: post #22

I suspect that it's perfectly valid to name a column "from" or any other SQL keyword so allowing a trailing comma would make the grammar ambiguous. Personally I agree with the sentiment, I find it annoying to have to juggle the commas on the last column name but I think there is likely a valid reason to do with making lexing easier to reason about.

Most SQL implementations do seem to allow you to name a column or a table with a keyword, but to refer to it you may need to put it in quotes or backticks.

I'm not sure if this is a solved problem at the level of the ANSI SQL spec or if every vendor does their own thing, but there's definitely plenty of precedent that ambiguous grammar is allowed and can be resolved.

Re: How about trailing commas in SQL?

#29

Post by adornKey »

emayljames wrote: post #19
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…

SELECT a , b , c FROM ... is the same as: SELECT a, b, c FROM ...

I updated my comment... On the first try the code-formatter here played some tricks with me.

The line before the Code has to be empty to get correct formatting.

Re: How about trailing commas in SQL?

#30

Post by firen777 »

elric wrote: post #2

Ugh. Why? To make copy/paste programming easier? To make query generation easier? When you're writing code to generate queries, it's worth doing it right. Just about every programming language has an easy way to take an array of strings and add a separator between each element. Like PHP's implode: implode(', ', ['foo', 'bar', 'baz']) == 'foo, bar, baz'. Every time I see a trailing comma, I think "is this a bug? did t…

From my own experience:

1. It makes git diff less noisy when I need to add new element at the end since you don't need to add an extra comma at the end of the now-second-to-last element.

2. It makes reordering the last element a lot more pleasant during development since you don't need to add and remove comma when you are moving the line.

And the same applies (or I wish applies) to SQL. Time and time again I wish trailing comma is a thing in SQL when I'm constructing and testing even slightly more complex queries.

Post reply on HN