operator precedence issues

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема operator precedence issues
Дата
Msg-id CAHyXU0zrXXKOy=3eLGG47Rd8pG5A8x--Woi0=WV_hqW=mOaUJQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: operator precedence issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: operator precedence issues  (Andres Freund <andres@2ndquadrant.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Compression of full-page-writes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Window functions can be created with defaults, but they don't work