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
