Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'd like to see closer adherence to the "usual" operator precedence. But
> I really *hate* having to explicitly call out each rule in the a_expr,
> b_expr, and/or c_expr productions. Any way around this?
It's not easy in yacc/bison, I don't believe. Precedence of an operator
is converted to precedence of associated productions, so there's no way
to make it work without an explicit production for each operator token
that needs a particular precedence.
In any case, the only way to make things really significantly better
would be if the precedence of an operator could be specified in its
pg_operator entry. That would be way cool, but (a) yacc can't do it,
(b) there's a fundamental circularity in the idea: you can't identify
an operator's pg_operator entry until you know its input data types,
which means you have to have already decided which subexpressions are
its inputs, and (c) the grammar phase of parsing cannot look at database
entries anyway because of transaction-abort issues.
Because of point (b) there is no chance of driving precedence lookup
from pg_operator anyway. You can only drive precedence lookup from
the operator *name*, not the input datatypes. This being so, I don't
see any huge advantage to having the precedence be specified in a
database table as opposed to hard-coding it in the grammar files.
One thing that might reduce the rule bloat a little bit is to have
just one symbolic token (like the existing Op) for each operator
precedence level, thus only one production per precedence level in
a_expr and friends. Then the lexer would have to have a table to
look up operator names to see which symbolic token to return them
as. Still don't get to go to the database, but at least setting a
particular operator name's precedence is a one-liner affair instead
of a matter of multiple rules.
regards, tom lane