This seems so minor it's hardly worth discussing. I in the 'who cares' camp.
How about trailing commas in SQL?
41–50 of 272 posts
Re: How about trailing commas in SQL?
#42This seems so minor it's hardly worth discussing. I in the 'who cares' camp.
The difference between you and a single celled archea is literally only many such small "who cares" changes.
Re: How about trailing commas in SQL?
#43Earlier quoted context omitted.
During prototyping, I'm frequently adding and removing entries from lists, or change their order. It's really annoying when you have to update the commas afterwards. Much nicer dev experience when ever entry ends with a comma, and you can juggle them around at will.
That’s why I use leading commas. Unless I change the first column, no problem.
Yea, and if you do trailing commas, "unless I change the last column, no problem". This is exactly the problem.
Supporting leading or trailing redundant comma are both good options. Not supporting either isn't.
Re: How about trailing commas in SQL?
#44To this still empty thread: how about we just stop arguing and add these damn commas everywhere? How about having human- and devenv-oriented languages finally, after how many decades?
In my opinion: because the Robustness principle [1] is a non-insignificant cause of bugs and SQL injection is a major player in the vulnerability game. The first case that jumps to me: if you write "a,b,c," you can't know whether you forgot a parameter, you passed an empty string where there shouldn't be one, or you intentionally left a trailing comma. And SQL already is human-oriented - compare your typical SQL to a…
This doesn't seem like it's much of an argument. Injecting `d, g` on the `b` place in your example will work fine. Trailing comma or no.
Re: How about trailing commas in SQL?
#45Earlier 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…
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.
Hard disagree.
Re: How about trailing commas in SQL?
#46I 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'd still want to have leading commas.
If the items in the list are long IF(...), maybe uses several lines and maybe contain SELECTs it's hard to see a missing trailing comma. At the start they're all lined up well, and it's very hard to get them wrong.
Re: How about trailing commas in SQL?
#47I 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.
I know that MySQL uses backticks, Postgres/Sqlite uses double quotes, and MS SQL Server uses square brackets, when using keywords for a column or table.
Re: How about trailing commas in SQL?
#48To this still empty thread: how about we just stop arguing and add these damn commas everywhere? How about having human- and devenv-oriented languages finally, after how many decades?
In my opinion: because the Robustness principle [1] is a non-insignificant cause of bugs and SQL injection is a major player in the vulnerability game. The first case that jumps to me: if you write "a,b,c," you can't know whether you forgot a parameter, you passed an empty string where there shouldn't be one, or you intentionally left a trailing comma. And SQL already is human-oriented - compare your typical SQL to a…
If you write "a,b,c" you can't know whether you forgot ",d" either, because if you wanted to type ",d" but got distracted and forgot it, the habit of leaving no trailing comma will lead to just "a,b,c" without ",d". And you can't know whether you forgot or mistyped a whole query either. What is this argument even, seriously? It's so weak that it is on par with suddenly having a stroke while programming. Which guardrails should we invent for that case?
SQL is fundamentally unsafe "forgot the item"-wise. It doesn't allow dynamic column selection, there's no type safety, nothing. If you want guarantees, maybe make a proper language with guarantees rather than justifying random side-effects of a comma being a syntax error sometimes.
Re: How about trailing commas in SQL?
#49Earlier quoted context omitted.
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.
Hard disagree.
I'm curious why you think so? I agree totally with the parent comment; when I iterate on a SQL query the most common place to make changes is near the end of the SELECT block, adding and removing and refining column expressions. I do the exact same "comma first" trick to make my life easier.
Re: How about trailing commas in SQL?
#50I 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…
You've moved the problem from the last to the first element though. Surely people would prefer to be able to do this SELECT a, b, c, FROM ... ?
The first element is modified less often than the last element. Often it's just an "id" column or something. Comma-first is a net win.