Merlin Moncure <mmoncure@gmail.com> writes:
> The operator precedence rules seem hard wired to not be able to be
> worked around, not matter what.
That's right. In the first place, bison is incapable of doing anything
other than hard-wired operator precedence. In the second, if we did
try to allow catalog-driven precedence, it would require catalog lookups
during the "raw parser" phase, which isn't going to work for a number
of implementation reasons; but worse than the implementation troubles
is that the grammar would then become fundamentally ambiguous, eg there
could be multiple correct parsings of A+B*C depending on what data types
A,B,C have. So precedence is hard-wired based on the operator name.
> I'm really scratching my head over this rule (via
> http://www.postgresql.org/docs/9.3/static/sql-syntax-lexical.html#SQL-PRECEDENCE):
> "When a schema-qualified operator name is used in the OPERATOR syntax,
> as for example in:
> SELECT 3 OPERATOR(pg_catalog.+) 4;
> the OPERATOR construct is taken to have the default precedence shown
> in Table 4-2 for "any other" operator. This is true no matter which
> specific operator appears inside OPERATOR()."
Yeah. I'd rather have said that it's the same precedence as for the
undecorated operator name, but again bison doesn't really have a way
to do that.
regards, tom lane