operator precedence issues

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: operator precedence issues
Date: 2013-08-30 22:35:04
Message-ID: CAHyXU0zrXXKOy=3eLGG47Rd8pG5A8x--Woi0=WV_hqW=mOaUJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hackers,

The operator precedence rules seem hard wired to not be able to be
worked around, not matter what. The pain point for me has always been
the division operator -- once in a while I end up in a situation where
I want to override it so that it wraps the divisor with NULLIF. There
is no way I can see to do that: custom operator (for example '//')
names evaluate in different precedence order which is a non-starter
essentially. That I'm ok with given the reasoning in the docs, but
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()."

That rule seems intentionally designed to make it impossible to to
override mathematical behaviors. Mainly curious -- was that
intentional?

merlin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-08-30 22:37:42 Re: Window functions can be created with defaults, but they don't work
Previous Message Robert Haas 2013-08-30 22:34:22 Re: Compression of full-page-writes