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