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

From Dagfinn Ilmari Mannsåker
Subject Re: Allowing additional commas between columns, and at the end of the SELECT clause
Date
Msg-id 877cfxhdpd.fsf@wibble.ilmari.org
Whole thread Raw
In response to Re: Allowing additional commas between columns, and at the end of the SELECT clause  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Allowing additional commas between columns, and at the end of the SELECT clause
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
>> Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
>>> Single trailing commas are a feature that's more and more common in
>>> languages, yes, but arbitrary excess commas is new to me. Could you
>>> provide some examples of popular languages which have that, as I can't
>>> think of any.
>
>> The only one I can think of is Perl, which I'm not sure counts as
>> popular any more.  JavaScript allows consecutive commas in array
>> literals, but they're not no-ops, they create empty array slots:
>
> 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.

> I realize the original proposal intended to restrict the legality of
> excess commas to only a couple of places, but to me that just flags
> it as a kluge.  ROW(...) ought to work pretty much the same as a
> SELECT list.

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.

> As already mentioned, if you can get some variant of this through the
> SQL standards process, we'll probably adopt it.  But I doubt that we
> want to get out front of the committee in this area.

Agreed.

>             regards, tom lane

- ilmari



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Direct SSL connection with ALPN and HBA rules
Next
From: Jacob Champion
Date:
Subject: Re: Direct SSL connection with ALPN and HBA rules