Feedback-ID: ie0a040ee:Fastmail
Message-ID: <4042a046-3dc9-4fc6-bfc6-62beb8492f27@eisentraut.org>
Date: Wed, 21 Jan 2026 17:59:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Provide support for trailing commas
To: Greg Sabino Mullane <htamfids@gmail.com>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
References: <CAKAnmmKVwP=yr8t8p8_QtrBFjyENLZyPxscJh4UrkCeqMQuhrw@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CAKAnmmKVwP=yr8t8p8_QtrBFjyENLZyPxscJh4UrkCeqMQuhrw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/4042a046-3dc9-4fc6-bfc6-62beb8492f27%40eisentraut.org>
Precedence: bulk

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.