Live data from Hacker News

How about trailing commas in SQL?

peter.eisentraut.org

201–210 of 272 posts

Re: How about trailing commas in SQL?

#201
post #5
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…

To make writing and maintaining sql easier. To make sql diffs better. To make sql more consistent with other languages. Every time this trips me up, it’s hand written SQL, because literally every other language I routinely use supports trailing commas. The additional complexity during codegen is barely existent. If you’re using an orm or code generator this will be an issue once at most (if and when you write your ow…

Everyone knows the hardest part about writing SQL is having to get Claude to tell you where the commas should go.

Re: How about trailing commas in SQL?

#202

Earlier quoted context omitted.

You can already do this without changing the SQL language spec. If you really care about the things you say, follow the other comments and make the first element special which is changed much less frequently.

So you can’t do it, you can do a different thing which (as I already answered in details elsewhere) still sucks but differently. Great contribution, thanks for nothing.

Curious to see your Postgres PR with this change in it. Is it done yet?

Re: How about trailing commas in SQL?

#204
post #176

Please god. I don't believe in you but maybe someone else does and will think me a kindred spirit worthy of mercy. Let me have trailing commas. There is no reason not to. It's backward compatible, easy to implement and would make the world so so so much better.

they are _not_ backwards compatible. That's a big part of the problem. A trailing comma is a syntax error for an SQL engine without support for it

[deleted]

Re: How about trailing commas in SQL?

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

Another trick is, if you're programmatically building a SQL statement - adding "WHERE 1=1" makes things easier ... like so: SELECT * FROM table WHERE 1=1 That way, if you want to filter down the result, everything programmatically appended just needs an "AND ..." at the start, like: SELECT * FROM table WHERE 1=1 AND age > 21 AND xyz = 'abc' ... Because without "WHERE 1=1", you'd had to handle the first condition diff…

I prefer “1=0 OR 1=1”, because when you delete all conditions you can keep 1=0 out of selection and it decays into a no-op rather than destroying a table:

  DELETE FROM table
  WHERE 1=0[ OR 1=1
    AND age > 21
    AND xyz = 'abc']
  ;
Brackets designate selection bounds before text deletion. The above just safely does nothing after you hit DEL.

Without that you’d have to delete whole [WHERE…], which leaves a very dangerous statement in the code.

Re: How about trailing commas in SQL?

#206
post #187

Earlier quoted context omitted.

I mean, yes, technically, but is anyone's code actually breaking because of this? Who is writing SQL queries expecting them to fail because of this reason? By your definition, "backwards compatible" doesn't mean anything. Literally everything will be a breaking change if you define "backwards compatible" like this.

I think the term you are looking for is "forwards compatible"! Old SQL queries will still run fine on engines that support the new syntax (they're forwards compatible.) New SQL queries with trailing commas will NOT run fine on engines that don't support trailing commas; this is not a backwards-compatible change. And that's fine.

> New SQL queries with trailing commas will NOT run fine on engines that don't support trailing commas; this is not a backwards-compatible change.

But they never ran fine on engines that didn't support trailing commas in the first place :/

What you're calling "forwards compatible" is what I call "backwards compatible". Frankly, I suspect most people expect "backwards compatible" stuff to work like this.

Is this distinction useful in any way?

Re: How about trailing commas in SQL?

#207
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.

Thinking that a new, least sucking data format won’t be used for configuration was a bigger mistake. Like, yeah, I will exchange all my data in JSON now, but store configs in a good old XMLNS XSLT DTMF?

Re: How about trailing commas in SQL?

#208
post #13
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…

[deleted]

Re: How about trailing commas in SQL?

#209
There is no correct answer for this; it’s a highly personal preference.

A lot of people prefer purity of grammar; these are the kind of folks who demand coding style guidelines and will be very unhappy if you violate their preference. They’re not wrong, but they have a very strong preference.

A lot of people don’t care so much about particular style decisions, but they want readable code that is easy to understand, maintain and modify. I think a lot of the trailing-comma-preferring people fall into this category. But again, it’s a preference and isn’t right or wrong.

There are probably also people who don’t care and compete in obfuscated code contests or try to minimize line counts by putting as many statements on each line as possible or otherwise writing genius-but-unreadable code by taking advantage of language and syntax idiosyncrasies. This is a preference too (although I consider it antisocial).

My preference is, if it’s unambiguous, allow trailing commas wherever there are lists, because it makes cut and paste operations much easier.

But at the end of the day that’s just my preference and not superior to anyone else.

Re: How about trailing commas in SQL?

#210
post #87

Earlier quoted context omitted.

> A lot of them don’t think this is worth the changeover. I think nobody wants to make trailing commas mandatory to use

Of course not. I don't think that has anything to do with it, though.

What changeover is there to be had if using trailing commas is not mandatory?
Post reply on HN