=?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
