Re: [PATCH] Provide support for trailing commas

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Provide support for trailing commas
Date: 2026-01-21 16:59:29
Message-ID: 4042a046-3dc9-4fc6-bfc6-62beb8492f27@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.01.26 21:35, Greg Sabino Mullane wrote:
> tl;dr Provide support for trailing commas, where possible and practical.

I was planning to work on this, so thanks for taking the heat. ;-)

I wrote a blog post about this about a year ago now:
https://peter.eisentraut.org/blog/2025/02/11/how-about-trailing-commas-in-sql

The intent of this was to gauge people's interest in terms of whether
and how to implement this and also whether and how to standardize it.

It looks like you opted for variant #2 I mentioned there.

There was also a Hacker News discussion:
https://news.ycombinator.com/item?id=43010365

Here is an approximate summary of the feedback. Note that the
commenters are all self-selected and either care about this topic a lot
either way, or they just like to correct other people on the Internet.

* About 50% of the commenters who expressed a clear opinion wanted
trailing commas.

* About 50% of the commenters who expressed a clear opinion were instead
fond of the leading-commas style:

SELECT a
, b
, c
FROM ...

* A number of commenters responded that they hate the leading-commas
style, undo it in code they control, or reject pull requests containing
such style.

* On the question for which constructs trailing commas would be most
useful, besides the mentioned SELECT list and CREATE TABLE content, a
number of commenters also wanted support in IN (a, b, c) lists.

* There was not a lot of feedback on the question of how broadly to add
support. Those who commented were about evenly split between add it
everywhere and add it just in a few important places.

Some more outlandish suggestions that are clearly not in scope:

* Many people also wanted some kind of trailing-delimiter support for
AND/OR in WHERE clauses.

* Many people suggested removing commas altogether.

* Or alternatively allowing commas everywhere as whitespace.

(Reading the current mailing list thread and the past ones that were
linked to, the arguments and spread opinions seems be pretty similar there.)

A selection of other sentiments (partially paraphrased):

* Just do it already.

* Don't let perfect be the enemy of good.

* Commenters complained about the "hackery" or "cleverness" associated
with leading-commas style and other similar workarounds.

* Commenters noted that they are sometimes confused when coming from
other programming languages that SQL does not support trailing commas.

* Some commenters noted that they specifically like certain SQL products
that support trailing commas and would miss it if they had to move to a
different product.

* A contributor to PrestoDB noted that there is "overwhelming support"
for adding trailing commas but also a "principled stand to not deviate
from the spec for superficial reasons".

* The lead developer of SQLite commented that he will add it "as soon as
PostgreSQL adds it".

I have found a few existing implementations that support some trailing
commas:

* BigQuery
* ClickHouse
* DuckDB
* Snowflake
* XTDB

DuckDB supports trailing commas in a number of clauses, but there does
not appear to be a well-defined system. BigQuery and Snowflake only
supports a trailing comma in the select list. Some of this is not
clearly documented.

I took the above summary to the SQL standard committee in September
(2025) and asked for a straw pool on how to proceed, in terms of the
standard. The clear answer was that the standard committee was not
interested.

This was mostly expected by me, but it also now gives us clarity that we
would not get ahead of the standard with this, as is sometimes raised as
a concern.

So, I would like to review your patch and consider this for inclusion
into PostgreSQL.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2026-01-21 16:59:51 Re: Inval reliability, especially for inplace updates
Previous Message David Geier 2026-01-21 15:45:06 Re: Reduce build times of pg_trgm GIN indexes