On Thu, 8 Jan 2026 at 03:07, Greg Sabino Mullane <[email protected]> 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 are no 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 comma support. 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
