On 27.01.23 16:34, Matthias van de Meent wrote:
On Fri, 27 Jan 2023 at 16:26, Peter Eisentraut
<peter.eisentr...@enterprisedb.com> wrote:
On 12.01.23 14:55, Matthias van de Meent wrote:
Matter of taste, I guess. But more importantly, defining an operator
gives you many additional features that the planner can use to
optimize your query differently, which it can't do with functions. See
the COMMUTATOR, HASHES, etc. clause in the CREATE OPERATOR command.
I see. Wouldn't it be better then to instead make it possible for the
planner to detect the use of the functions used in operators and treat
them as aliases of the operator? Or am I missing something w.r.t.
differences between operator and function invocation?
E.g. indexes on `int8pl(my_bigint, 1)` does not match queries for
`my_bigint + 1` (and vice versa), while they should be able to support
that, as OPERATOR(pg_catalog.+(int8, int8)) 's function is int8pl.
I have been thinking about something like this for a long time.
Basically, we would merge pg_proc and pg_operator internally. Then, all
the special treatment for operators would also be available to
two-argument functions.
And single-argument functions in case of prefix operators, right?
Right.
(The removal of postfix operators is helpful to remove ambiguity here.)
