How about trailing commas in SQL?

> 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 code formatting that involve something "clever". Your example of leading commas above for example. Another example is code ligatures. It's as if there's a dividing line of taste here where one either feels delight at the clever twist, or the total opposite, rarely anything in between. I happen to dislike these kinds of things (and particularly loathe code ligatures) but it is often hard to justify exactly why beyond taste.

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. But it's more than that -- you could fix those functional issues and I'll still dislike them.

I often do this with boolean WHERE filters when I'm doing interactive exploration on some data:

    SELECT ...
    WHERE
      foo = 1
      AND bar = 2

The solution is to start with "WHERE true":

    SELECT ...
    WHERE true
      --AND foo = 1
      AND bar = 2

(Putting the AND at end of each line has the same problem, of course, and requires putting a "true" at the bottom instead.)

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

It’s also completely wonky in many contexts e.g. CREATE TABLE. Trailing commas always works.

> I'd suggest to maybe just change your coding style - and make the start of the list special - instead of the end.

Supporting trailing commas means neither is special.

I too prefer leading commas, especially useful when you're prototyping a query. I also picked up the ORM trick of starting your WHERE clause with 1=1 so that every meaningful filter can start with AND ... I'm not as consistent with this one, but it's handy too.

I catch (friendly) flak for my zealot SQL formatting (capitalization, indenting) and know it doesn't impact the execution, but there's something about working in logic / set theory that matches with strict presentation; maybe helps you think with a more rigid mindset?

I do this as well.

on top i often do a pad entry so that the elements are all on their own line

  SELECT 1 as pad
    , a
    , b

what would be helpful is both LEADING and trailing commas

so I am suggesting:

  SELECT
    , a
    , b

Developer ease leads to less mistakes is my conjecture.

IMHO this is one of the ugliest formattings. Whenever I see that i try to revert and avoid at all costs. I know it's a personal flavor, yet. I might be too opinionated..

Mode Analytics published some data years ago showing that SQL programmers who preferred leading commas had a lower rate of errors than programmers who used trailing commas. [0]

0 - https://mode.com/blog/should-sql-queries-use-trailing-or-lea...

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

?

Most of that additional syntax surface area would also benefit from trailing commas. For example, `SELECT * EXCLUDE (a, b, ...)`, or even `FROM a, b, ...`.

Doesn't feel like a breaking change to me.

I feel the same way about SQL too, it's set and difficult to shift. But I also look at PRQL longingly - https://prql-lang.org/

> lack of support for trailing commas in JSON

This, 100%! And the lack of comments.

Funny I’m the exact opposite: I essentially never write JSON by hand, or add json content to repositories, so could not care less about the lack of trailing commas, I do semi routinely write or review SQL.

I've been bitten by trailing commas in my python+sql code repeatedly, it's an easy mistake to make when python itself has trailing commas (which I make deliberate use of).

The closing tags should be optional too.

[{},{},,,,{},,

Should be fine. Now you can push things to the eof.

I get where they're coming from though. Having trailing commas work in some common cases but most other cases where there are commas would be weird and definitely result in confusion. More confusion that knowing that trailing commas aren't a thing in SQL, currently.

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 data operation in K [2]. It just so happens that some things are hard and off-by-one errors are famously near the top of the list [3].

Whenever a database complains that your SQL query contains a trailing comma it's a sign that you may not have paid enough attention to your arguments (or even worse, that you're building queries by hand instead of using prepared statements). From where I stand, not allowing trailing commas is a feature, not a bug, and I would therefore object against them.

[1] "be conservative in what you do, be liberal in what you accept from others" - https://en.wikipedia.org/wiki/Robustness_principle#Criticism

[2] https://news.ycombinator.com/item?id=42999650

[3] http://www.randomprogramming.com/2014/09/quote-of-the-week-h...

Genuinely, I'd love to see this approach be taken: allow for a set of characters to be used as list delimiters. I personally like the set to be comma, semicolon, and newline, but of course this set would need to be varied depending on other syntax (e.g. in SQL, we wouldn't want semicolon to be used for this).

Having newline be a valid list separator is particularly nice because it solves the "trailing comma" and "comma-first" style workarounds in a visually elegant way. The newline already provides a visual separator; we can already tell that we're at the end of most lists by way of having another keyword appear next without needing to rely on a lack of commas, for example:

    select
        id
        name
        email
    from users

Because there's existing implementations that would interpret that as aliasing column names.

``` SELECT Field AS Renamed, OtherField AS AlsoRenamed ```

and

``` SELECT Field Renamed, OtherField AlsoRenamed ```

are semantically equivalent.

Because in SQL whitespace is already used for all manner of special syntax.

That said, generating SQL from s-expressions can be a very pleasant experience.

Wouldn’t just trailing solve your issue?

    SELECT
    a,
    b,
    c,
    From Foo

That's correct, and I absolutely love it. If I move to a new role where BigQuery is not the data warehouse of choice, I think this will be the thing I'll miss most.

It's nice when bigquery and python together for data analysis that little things like that are congruent