Indeed. I think it carries substantial risk of creating large parsing problems down the road, when we try to integrate whatever random syntax the SQL committee comes up with next. And frankly, I don't agree that it'd be beneficial.
Hmmm, I was partly inspired to write this by your comment in the second link you referenced, in which you said:
> 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.
So, this is an attempt to be more comprehensive, which has been one of the major critiques of previous attempts to apply things to a small subset of the things we parse.
No, it's not yet in the SQL standard, but why not be more liberal in what we accept, 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.
Unsurprisingly, I also don't agree that new SQL committee changes will be that hard to support around some trailing comma support. The syntax moves slowly, and very few things will impact our comma-separated lists. The most likely things is additional modifiers e.g. RESTART IDENTITY but once we are handling one, we already have a framework in place to handle future ones.
