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

251–260 of 272 posts

Re: How about trailing commas in SQL?

#251

Post by cnity »

JadedBlueEyes wrote: post #189
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…

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

How could this possibly be done for ligatures which don't maintain their horizontal position though? `!=` will usually be shown as an equals sign with a line through it right down the middle.

Re: How about trailing commas in SQL?

#252

Post by wruza »

trailingcoma wrote: post #214
wruza wrote: post #212

Earlier quoted context omitted.

You really want us to focus on more important impediments (whatever that means)? Just be glad we only want commas and add them already. If that trivial why even argue.

I anxiously await your pull request.

https://postgrespro.com/list/thread-id/1853280

Re: How about trailing commas in SQL?

#253

Post by Jean-Papoulos »

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…

This is way less readable to me, because now my brain has to parse "a comma, actual thing" instead of a list of things.

Re: How about trailing commas in SQL?

#254

Post by rollcat »

specialist wrote: post #238
rollcat wrote: post #177

Earlier quoted context omitted.

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

I'm slowly shifting in that direction as well, but the libraries built around this style are far less mature / mainstream. Django is the "boring" solution and gets hella work done.

Re: How about trailing commas in SQL?

#255

Post by quietbritishjim »

btilly wrote: post #163
quietbritishjim wrote: post #51

Earlier quoted context omitted.

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

Any new style will look bad, simply because it is new to us. But you quickly get used to it. After that, it is about minimizing errors. Leading commas minimize errors, and is a style that is portable across databases.

> Any new style will look bad, simply because it is new to us.

I agree that new styles and syntaxes can take some getting used to. When I went from Pascal to C, braces seemed awful but I now think punctuation is much clearer than words for delimiting blocks.

But the discussion here is about whether to introduce a new clearer style. Taken on this context, your comment amounts to defending any existing syntax, no matter how horrific, because you'll get used to it eventually.

Re: How about trailing commas in SQL?

#256

Post by andy81 »

_blk wrote: post #101

When do we get an object shell (powershell, there I said it) instead of old school strings? Been using bash for over 20y, but MS had to make it popular.. I wouldn't mind at least a proof of concept for SQL

What would it offer that you can't already get from DBATools, LINQ, and ORMs more generally?

Re: How about trailing commas in SQL?

#257

Post by paulddraper »

cnity wrote: post #251
JadedBlueEyes wrote: post #189

Earlier quoted context omitted.

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

How could this possibly be done for ligatures which don't maintain their horizontal position though? `!=` will usually be shown as an equals sign with a line through it right down the middle.

For code editing, usually ligatures are spaced relative to their expanded variant.

E.g., ≠ is as wide as two characters.

Re: How about trailing commas in SQL?

#258

Post by Olreich »

wruza wrote: post #207
Cthulhu_ wrote: post #77

Earlier quoted context omitted.

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?

Store configs in the program if you can. Store in INI, TOML, or something similarly simple for humans if you must. Never use anything that requires matching syntax as the default (closing tags and matched brackets being the two main ones).

JSON is already strictly worse than XML though as it doesn’t support comments and multi-line strings in a sane way.

Re: How about trailing commas in SQL?

#259

Post by vizzier »

datadrivenangel wrote: post #86
touseol wrote: post #76

Earlier quoted context omitted.

What your mind rejects, mine finds freeing. What's idiomatic and natural depends on personal experience and evolves, as does the culture around you. There was a time in my life when I may have rejected leading commas as well, but at some point I came around to them and have never looked back. It works for me. I legitimately find it easier on my mind, and it has caused me far fewer annoyances than a comma-less last co…

Leading commas are the way!

People seem to think nothing of putting all other syntax on a new line (+, -, ||, &&, AND, OR are all fine) but as soon as you put a comma on a new line everyone loses their minds.

Re: How about trailing commas in SQL?

#260

Post by wruza »

Olreich wrote: post #258
wruza wrote: post #207

Earlier quoted context omitted.

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?

Store configs in the program if you can. Store in INI, TOML, or something similarly simple for humans if you must. Never use anything that requires matching syntax as the default (closing tags and matched brackets being the two main ones). JSON is already strictly worse than XML though as it doesn’t support comments and multi-line strings in a sane way.

Thanks, but I tend to ignore this. Every time you, as a direct end-user, provide feedback on format or software, someone appears with a whole philosophy around why you shouldn't be like that and what you should do instead. And sometimes there's no "why" part even.

But I really don't need philosophy. I know what I want, and I want json with $subj, //comments and optional key quoting. Feels like some people just love making inconvenient things standard and/or teaching others how to live. (I mean the idea "json is not for X" here, not your comment)

Post reply on HN