Re: Allowing additional commas between columns, and at the end of the SELECT clause - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allowing additional commas between columns, and at the end of the SELECT clause
Date
Msg-id 762525.1715620475@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing additional commas between columns, and at the end of the SELECT clause  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
List pgsql-hackers
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I'm fairly down on this idea for SQL, because I think it creates
>> ambiguity for the ROW() constructor syntax.  That is:
>>     (x,y) is understood to be shorthand for ROW(x,y)
>>     (x) is not ROW(x), it's just x
>>     (x,) means what?

> Python has a similar issue: (x, y) is a tuple, but (x) is just x, and
> they use the trailing comma to disambiguate, so (x,) creates a
> single-item tuple.  AFAIK it's the only place where the trailing comma
> is significant.

Ugh :-(.  The semantic principle I'd prefer to have here is "a trailing
comma is ignored", but what they did breaks that.  But then again,
I'm not particularly a fan of anything about Python's syntax.

> 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.
I'm not sure if any other ambiguities arise, though.  SQL has
a lot of weird syntax corners (and the committee keeps adding
more :-().

            regards, tom lane



pgsql-hackers by date:

Previous
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: Improving information_schema._pg_expandarray()
Next
From: Tom Lane
Date:
Subject: Re: Fix out-of-bounds in the function GetCommandTagName