Merlin Moncure 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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 3 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 30, '13 at 10:35p
activeAug 30, '13 at 10:48p
posts3
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2017 Grokbase