241–250 of 272 posts
I could have missed something but I don't see anything that would be impossible to parse without commas so long as there's at least one character of whitespace separation.
What if they simplified it so commas were ignored and thus optional. Then they are purely for readability, allowing for whichever approach a project preferred as their standard (no commas, traditional SQL, with leading commas, with trailing conmas). I could have missed something but I don't see anything that would be impossible to parse without commas so long as there's at least one character of whitespace separation…
Earlier quoted context omitted.
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.
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'm not sure if this is an example of code ligatures, but I used to work with a guy who had configured his editor so that "=>" was replaced with some kind of special arrow character, and it used to drive me nuts. When I read code, I want to know what's actually there, and not have to ask "what does that arrow actually mean?"
Earlier quoted context omitted.
I'm not sure if this is an example of code ligatures, but I used to work with a guy who had configured his editor so that "=>" was replaced with some kind of special arrow character, and it used to drive me nuts. When I read code, I want to know what's actually there, and not have to ask "what does that arrow actually mean?"
But you have demonstrated that you know what the arrow means. Do you have your editor configured to display special symbols for all whitespace characters? Including newlines? Are you sure that you aren't just annoyed by looking at stuff you're not used to?
Code ligatures make text harder to read because they are not text, expecially when many of those ligatures are identical to actually existing unicode characters making the gliph more ambiguous than they laready were.
IMHO symbol should reflex their use: the dozens of different arrows used in math are meant to be handwritten or at least to be seen as a complex gliph.
=> and -> in almost every programming language is a = or a - followed by a >. We could very easily make a language where ⇒ is an operator (https://isabelle.in.tum.de/ does for example IIRC) but most languages use simple ascii characters for grammar for good reasons.
IMHO code ligatures are worse than a cursive coding font.
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…
SELECT
, a
, b
, c
FROM ...
SELECT a,
b,
c,
FROM ...
SELECT
a,
b,
c,
FROM ...
Earlier quoted context omitted.
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.
Ideally there'd be a syntax that looked like a function `SELECT(a, b, c, d)` with a totally distinct variant for specifying types `TSELECT(a, int, b, null, c, text, d, timezonetz)`. The big problem here is the seemed-good-in-the-70s syntax that died with SQL. In the best of all possible worlds they could have just used Lisp as the foundation then let people macro/transpile their own syntaxes. A subtle flaw in SQL is…
Earlier quoted context omitted.
I'm not sure if this is an example of code ligatures, but I used to work with a guy who had configured his editor so that "=>" was replaced with some kind of special arrow character, and it used to drive me nuts. When I read code, I want to know what's actually there, and not have to ask "what does that arrow actually mean?"
But you have demonstrated that you know what the arrow means. Do you have your editor configured to display special symbols for all whitespace characters? Including newlines? Are you sure that you aren't just annoyed by looking at stuff you're not used to?
I actually have my editor configured to display special symbols for all control characters except U+000A NEW LINE (that includes U+0009 HORIZONTAL TABULATION as well, this is actually a control character, not a whitespace) and all whitespace characters except U+0020 SPACE.
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.
It's backwards compatible from the perspective of the database - the db will continue to support queries from older versions.
I believe you're speaking from different perspectives.