Re: [PATCH] Provide support for trailing commas
| От | David Rowley |
|---|---|
| Тема | Re: [PATCH] Provide support for trailing commas |
| Дата | |
| Msg-id | CAApHDvoYZe_983Rk3kjLg3uiUSxHKXFEYPMnz6XH+yJkM-_3dg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Provide support for trailing commas (Greg Sabino Mullane <htamfids@gmail.com>) |
| Ответы |
Re: [PATCH] Provide support for trailing commas
|
| Список | pgsql-hackers |
On Thu, 8 Jan 2026 at 03:07, Greg Sabino Mullane <htamfids@gmail.com> wrote: > No, it's not yet in the SQL standard, but why not be more liberal in what we accept, I believe the concern is that it could hinder us from being able to implement new SQL standard features. Back in 8.4, "AS" became optional in the SELECT list. I recall that it was a bit tricky to get around some grammar ambiguities with that. There's some detail on that in the comment added in e67867b26. > and not have people invent various workaround hacks (e.g. dummy columns)? Because the parser eats the comma, there areno behavioral changes post-parsing. Why do people have to add dummy columns? Is this because these people don't know how to program a check to see if they're on the first iteration of a loop or not? > Unsurprisingly, I also don't agree that new SQL committee changes will be that hard to support around some trailing commasupport. To me, that seems like a risky thing to disagree with. I expect you don't have a vision of what the standard committee might dream up infinitely far into the future. Personally, I don't want this feature. I'd rather receive an error message when I make silly mistakes in code that I write. If I have code to dynamically build an SQL statement and I have a bug that causes a variable that stores a column name to sometimes be an empty string, with your patch, I'll get an error message in all cases unless the column's position is last. I want the error at all times, not sometimes. David
В списке pgsql-hackers по дате отправления: