> allow multiple generic operators in expressions without the use of
> parentheses
I could just let this one go until it dies a quiet death, but...
To parse "multiple generic operators", per the example
select oid @ oid @ oid from table;
one would have to change the associativity of many operators from
non-associative (the correct assumption) to left- or right associative
(the wrong thing to do). If we are going to allow operator extensibility
we cannot make assumptions about the precedence order of operators, and
should require parentheses to break the ambiguity.
Unless someone has a good proposal on how to change the standard rules
of arithmetic, or on how to change the parser to allow
operator-dependent precedence in an extensible way, then we shouldn't
bother tracking this as a problem statement imho.
- Tom