=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilm...@ilmari.org> writes: > Tom Lane <t...@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