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

121–130 of 272 posts

Re: How about trailing commas in SQL?

#121

Post by wruza »

NoMoreNicksLeft wrote: post #114
atombender wrote: post #105

Earlier quoted context omitted.

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…

God, everyone's going to hate me for this. (I will have earned it, I think.) SELECT ... WHERE foo = 1 AND bar = 2 Each keyword gets a new line, the middle gutter between keyword and expressions stays in the same place, and things get really, really fugly if I need a subselect or whatever. Any given line can be commented out. (And no, none of that leading comma bullshit, somehow that looks nasty to me.) Downvote this…

Since we're already here, we could think about trailing AND, actually. Look:

  SELECT a, sum(b),
   WHERE foo = 1
     AND GROUP BY a
Sounds pretty SQL to me.

Re: How about trailing commas in SQL?

#122

Post by Supermancho »

jghn wrote: post #84
sixothree wrote: post #68

Earlier quoted context omitted.

People who write code.

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.

Re: How about trailing commas in SQL?

#124

Post by recursive »

tlb wrote: post #104
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've done this for arrays in JSON files, so that git merge will merge two changes that append to the list without a conflict. I think the right answer is to fix the merge algorithm to handle some common cases where an inserted line logically includes the delimiter at the end of the previous line.

The problem with that is that it's invalid json. Some things might tolerate it though.

Re: How about trailing commas in SQL?

#125

Post by OccamsMirror »

ezekiel68 wrote: post #107

I love it. I can see no downsides (as long as the updated implementations are well tested). I reject any argument about how mature SQL is at this point. Just bump the version number (SQL 25) if necessary and make it so.

Doesn't feel like a breaking change to me.

Re: How about trailing commas in SQL?

#126

Post by fngjdflmdflg »

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…

Huh, I've always used "WHERE 1 = 1 AND ...". Using `true` looks more clean.

Re: How about trailing commas in SQL?

#127

Post by cnity »

Quekid5 wrote: post #56
cnity wrote: post #13

Earlier quoted context omitted.

> 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…

> 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. If I `/=` in vim (find equals signs), should the "!=" ligature be highlighted? If it is, then it is misrepresenting the state: if I then press delete, the highlighted ligature won't actually be removed, only part of it will be.

2. In javascript the `===` operator is less visually distinct from `==` since if there are no comparisons nearby I have to judge from the length somehow and it takes longer, adding some additional comprehension fatigue.

Anyway like I said, you can probably try to fix all of these with weird special case handling but it's just fighting the underlying assumption my editor makes (and my brain has learned to understand): a source file is a list of runes. That's how I like to think about it.

Anyone is free to think otherwise. They're just in that other camp and that's OK. But I don't like them personally.

Re: How about trailing commas in SQL?

#128

Post by recursive »

Cthulhu_ wrote: post #77
reddalo wrote: post #11

Earlier quoted context omitted.

> lack of support for trailing commas in JSON This, 100%! And the lack of comments.

JSON5 allows comments, it's been around since 2012. That said, JSON is not meant for humans / manual editing, and deciding to use it for configuration files was a mistake.

How am I supposed to make changes to this configuration file?

Re: How about trailing commas in SQL?

#129

Post by yellowapple »

wruza wrote: post #121
NoMoreNicksLeft wrote: post #114

Earlier quoted context omitted.

God, everyone's going to hate me for this. (I will have earned it, I think.) SELECT ... WHERE foo = 1 AND bar = 2 Each keyword gets a new line, the middle gutter between keyword and expressions stays in the same place, and things get really, really fugly if I need a subselect or whatever. Any given line can be commented out. (And no, none of that leading comma bullshit, somehow that looks nasty to me.) Downvote this…

Since we're already here, we could think about trailing AND, actually. Look: SELECT a, sum(b), WHERE foo = 1 AND GROUP BY a Sounds pretty SQL to me.

This is cursed, but also entirely consistent with the trailing comma proposal.

It'd sure look funny if all keywords that connected clauses together were trailable, though.

    SELECT a, sum(b),
    FROM stuff
    WHERE foo = 1
       OR GROUP BY a
Or just as horrifying:

    SELECT a, b, c,
    FROM foo
    UNION ALL
    SELECT a, b, c,
    FROM bar
    UNION ALL

Re: How about trailing commas in SQL?

#130

Post by yellowapple »

masklinn wrote: post #21
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 comm…

I don't want to write commas at all. I want to write

    SELECT
        a
        b
        c
    FROM d
Or even

    SELECT a b c FROM d
Because now selected values are uniform and there's no superfluous punctuation to worry about.
Post reply on HN