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

181–190 of 272 posts

Re: How about trailing commas in SQL?

#181

Post by maleldil »

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

A good compromise is an option from the Kitty terminal[1]: if your cursor is on top of the ligature, show the individual characters.

[1] `disable_ligatures cursor`

Re: How about trailing commas in SQL?

#182

Post by marcosdumay »

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…

> Before people start to mess with the standard

No, it's still a really good reason to mess with the standard.

While the standard doesn't evolve into something slightly modern, yes, that workaround is better than the way people usually write SQL. But its existence isn't a reason not to fix the fundamental problem.

Re: How about trailing commas in SQL?

#183

Post by dhruvrajvanshi »

birb07 wrote: post #176
tqwhite wrote: post #167

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

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.

Re: How about trailing commas in SQL?

#184

Post by macbem »

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.

even if it wasn't meant for humans and manual editing, it works reasonably well for these usecases

Re: How about trailing commas in SQL?

#185

Post by andy81 »

dewey wrote: post #180
tiffanyh wrote: post #153

Earlier quoted context omitted.

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…

You can also just do "where true", easier to type.

Not in e.g. MSSQL

Re: How about trailing commas in SQL?

#186

Post by marcosdumay »

yellowapple wrote: post #130
masklinn wrote: post #21

Earlier quoted context omitted.

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.

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.

Re: How about trailing commas in SQL?

#187

Post by tibbar »

dhruvrajvanshi wrote: post #183
birb07 wrote: post #176

Earlier quoted context omitted.

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

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.

Re: How about trailing commas in SQL?

#188

Post by benhurmarcel »

dhruvrajvanshi wrote: post #183
birb07 wrote: post #176

Earlier quoted context omitted.

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

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.

https://xkcd.com/1172/

Re: How about trailing commas in SQL?

#189

Post by JadedBlueEyes »

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 can't place the cursor half-way through a ligature and so on.

That sounds like a bug in the editor. Ligatures are incredibly common font features even outside of programming, even sequences like fi are often ligatures.

Post reply on HN