Re: Allowing additional commas between columns, and at the end of the SELECT clause
От | Tom Lane |
---|---|
Тема | Re: Allowing additional commas between columns, and at the end of the SELECT clause |
Дата | |
Msg-id | 762525.1715620475@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Allowing additional commas between columns, and at the end of the SELECT clause (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>) |
Список | pgsql-hackers |
=?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
В списке pgsql-hackers по дате отправления: