Robert Haas <robertmhaas@gmail.com> writes:
> I think there would be a lot of value in coming up with some kind of
> incremental improvement here; this is a common annoyance for users
> migrating from other database systems (and one in particular).
Agreed, but ...
> Technically, that doesn't look hard to do: (1) remove the rule that
> allows postfix ops, or restrict it to operators beginning with ! or
> where OPERATOR() notation is used, or whatever; (2) add a new
> production target_el_keyword that includes some or all of the keywords
> that don't cause grammar conflicts, (3) add a rule that target_el can
> be "a expr target_el_keyword", (4) profit. Or, since that would make
> maintaining target_el_keyword a nuisance, split unreserved_keyword
> into two new categories, unreserved_keyword and
> very_slightly_reserved_keyword, and update elsewhere accordingly.
> However, I foresee that Tom will object to the idea of creating a new
> category of keywords, and I'm happy to do something else if we can
> figure out what that other thing is.
Not *nearly* as much as I'd object to mostly-breaking postfix operators.
Now admittedly, if the Berkeley guys had never put those in, nobody
would miss them. But they're there, and I'm afraid that users are
likely depending on them. Neither of your suggestions above would be
any less damaging to such users than removing the feature altogether.
> I'm not immediately sure how to
> use operator precedence to resolve these ambiguities;
Unfortunately, this thread got swapped out of my brain long ago,
so I'm not sure what I was talking about either. I could take
another look sometime.
regards, tom lane
