Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> What I was hoping to get out of this was to resolve some of the weird
> precedence hacks that were blamed on postfix operators.
Yeah, I was thinking about that too, but hadn't gotten to it.
> But building on your patch, the best I could achieve was
> -%nonassoc IDENT GENERATED NULL_P PARTITION RANGE ROWS GROUPS PRECEDING
> FOLLOWING CUBE ROLLUP
> +%nonassoc IDENT PARTITION RANGE ROWS GROUPS PRECEDING FOLLOWING CUBE
> ROLLUP
> which is a pretty poor yield.
I'd hoped for better as well. Still, it's possible this would save us
from greater pain in the future, seeing that the SQL committee seems
resolutely uninterested in whether the syntax they invent is parsable.
(Also, there are other factors here: I think at least some of those
precedence hacks are there to avoid fully reserving the associated
keywords.)
> Maybe this isn't worth it after all.
It'd be nice to have a better yield from removing a user-visible
feature. Perhaps there would be no complaints about removing
postfix ops, but if there are I want to be able to point to some
substantial benefit that users get from it. (Which is why I focused
on the optional-AS business to start with ... users don't care
about how many precedence hacks we need.)
regards, tom lane