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.

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

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

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?

ClickHouse has support for trailing commas for several years.

I recommend looking at ClickHouse (https://github.com/ClickHouse/ClickHouse/) as an example of a modern SQL database that emphasizes developer experience, performance, and quality-of-life improvements.

I'm the author of ClickHouse, and I'm happy to see that its innovation has been inspired and adopted in other database management systems.

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.

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

  SELECT *
  FROM table
  WHERE 1=1
  AND age > 21
  AND xyz = 'abc' ...

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

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

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.

OP is one of 7 PostgreSQL core team members. That's kind of his job to massively overthink this :)

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

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/

Douglas Crockford made a commitment that JSON would never, ever get better. He promised us that it would always suck. He is as good as his word.

It has the small benefit that you never, ever have to worry about running into an old version of a JSON parser that bounces your fancy trailing commas.

Worth it? Not to me but Douglas Crockford does not care what I think. Or you either, apparently.

What extra "if"?

  ', '.join(fields)

The closing tags should be optional too.

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

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

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

How about we just do nothing and people write syntactically-correct SQL instead of demanding everyone and everything else change? I'm sorry, is this really the most important impediment to software development right now? Some guy's beef with the SQL parser?

I always start with "SELECT COUNT() FROM ..." for this reason, and then go back and replace the COUNT() when I get a handle on the tables/filters/groups involved..

Doesn't feel like a breaking change to me.

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

It's not just cosmetic, though, as now in order to add a new entry at the end you need to change two lines of code, which means your git blame is no longer accurate.

Or one database can have it as an option and that "specific type of developer" can just use that?