Tom Lane <t...@sss.pgh.pa.us> writes: > =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilm...@ilmari.org> writes: >> Matthias van de Meent <boekewurm+postg...@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