MIME-Version: 1.0
References: <CAKAnmmKVwP=yr8t8p8_QtrBFjyENLZyPxscJh4UrkCeqMQuhrw@mail.gmail.com>
 <1619826.1767732539@sss.pgh.pa.us>
In-Reply-To: <1619826.1767732539@sss.pgh.pa.us>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Wed, 7 Jan 2026 09:06:54 -0500
Message-ID: <CAKAnmmJx7C5APcw-hE2+EpM+9biova-5j+U-xHU3gGqkfd=vhw@mail.gmail.com>
Subject: Re: [PATCH] Provide support for trailing commas
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000d31ba10647cccfec"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmmJx7C5APcw-hE2%2BEpM%2B9biova-5j%2BU-xHU3gGqkfd%3Dvhw%40mail.gmail.com>
Precedence: bulk

--000000000000d31ba10647cccfec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 6, 2026 at 3:48=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Indeed.  I think it carries substantial risk of creating large parsing
> problems down the road, when we try to integrate whatever random syntax t=
he
> SQL committee comes up with next.  And frankly, I don't agree that it'd b=
e
> beneficial.
>

Hmmm, I was partly inspired to write this by your comment in the second
link you referenced, in which you said:

> Yeah, a more principled approach would be to not special-case target
> lists, but to allow one (and only one) trailing comma everywhere:
> select, order by, group by, array constructors, row constructors,
> everything that looks like a function call, etc.

If it can be made to work everywhere, that would get my vote.

So, this is an attempt to be more comprehensive, which has been one of the
major critiques of previous attempts to apply things to a small subset of
the things we parse.

No, it's not yet in the SQL standard, but why not be more liberal in what
we accept, and not have people invent various workaround hacks (e.g. dummy
columns)? Because the parser eats the comma, there are no behavioral
changes post-parsing.

Unsurprisingly, I also don't agree that new SQL committee changes will be
that hard to support around some trailing comma support. The syntax moves
slowly, and very few things will impact our comma-separated lists. The most
likely things is additional modifiers e.g. RESTART IDENTITY but once we are
handling one, we already have a framework in place to handle future ones.


Cheers,
Greg

--000000000000d31ba10647cccfec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jan 6, 2026 at 3:48=E2=80=AFPM To=
m Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; w=
rote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Indeed.=C2=A0 I think it carries substan=
tial risk of creating large parsing problems down the road, when we try to =
integrate whatever random syntax the SQL committee comes up with next.=C2=
=A0 And frankly, I don&#39;t agree that it&#39;d be beneficial.<br></blockq=
uote><div><br></div><div>Hmmm, I was partly inspired to write this by your =
comment in the second link you referenced, in which you said:</div><div><br=
></div><p style=3D"box-sizing:border-box;margin-top:0px;color:rgb(0,0,0);fo=
nt-family:monospace,monospace;font-size:10.7333px">&gt; Yeah, a more princi=
pled approach would be to not special-case target<br style=3D"box-sizing:bo=
rder-box">&gt; lists, but to allow one (and only one) trailing comma everyw=
here:<br style=3D"box-sizing:border-box">&gt; select, order by, group by, a=
rray constructors, row constructors,<br style=3D"box-sizing:border-box">&gt=
; everything that looks like a function call, etc.</p><span style=3D"color:=
rgb(0,0,0);font-family:monospace,monospace;font-size:10.7333px"><br></span>=
<div><span style=3D"color:rgb(0,0,0);font-family:monospace,monospace;font-s=
ize:10.7333px">If it can be made to work everywhere, that would get my vote=
.</span></div><div><br></div><div>So, this is an attempt to be more compreh=
ensive, which has been one of the major critiques of previous attempts to a=
pply things to a small subset of the things we parse.</div><div><br></div><=
div>No, it&#39;s not yet in the SQL standard, but why not be more liberal i=
n what we accept, and not have people invent various workaround hacks (e.g.=
 dummy columns)? Because the parser eats the comma, there are no behavioral=
 changes post-parsing.</div><div><br></div><div>Unsurprisingly, I also don&=
#39;t agree that new SQL committee changes will be that hard to support aro=
und some trailing comma support. The syntax moves slowly, and very few thin=
gs will impact our comma-separated lists. The most likely things is additio=
nal modifiers e.g. RESTART IDENTITY but once we are handling one, we alread=
y have a framework in place to handle future ones.</div><div><br></div><div=
><br></div></div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr=
"><div>Cheers,</div><div>Greg</div><div><br></div></div></div></div>

--000000000000d31ba10647cccfec--