Re: COMMUTATOR doesn't seem to work - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COMMUTATOR doesn't seem to work
Date
Msg-id 12292.1340379362@sss.pgh.pa.us
Whole thread Raw
In response to Re: COMMUTATOR doesn't seem to work  (D'Arcy Cain <darcy@druid.net>)
Responses Re: COMMUTATOR doesn't seem to work
List pgsql-hackers
"D'Arcy Cain" <darcy@druid.net> writes:
> ... The issue here is that the operator is SC but
> the args are different types.

Well, that's a weird way of defining self-commutating, but ...

> It would be nice if there was a way
> to automatically generate code that reverses arguments.  Maybe such
> a thing belongs in the CREATE FUNCTION command.

> Or, I guess this works and keeps from creating a second C function:

> CREATE OR REPLACE FUNCTION eq(chkpass, text)
>      RETURNS bool
>      STRICT
>      AS 'chkpass.so', 'chkpass_eq'
>      LANGUAGE 'c'
>      RETURNS NULL ON NULL INPUT;

> CREATE OR REPLACE FUNCTION eq(text, chkpass)
>      RETURNS bool
>      AS 'select eq($2, $1);'
>      LANGUAGE SQL
>      RETURNS NULL ON NULL INPUT;

The thing is that either of those approaches is hugely more expensive
than just providing a second C function.  It costs probably thousands
of cycles to inline that SQL function, each time it's used in a query.
I doubt that an "auto reverse the arguments" facility would be very
much cheaper.  You could maybe argue that the aggregated maintenance
and space costs of all the commutator-pair functions are enough to
justify having some such solution instead, but I'm doubtful --- and
even if true, getting from here to there would be painful.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Allow WAL information to recover corrupted pg_controldata
Next
From: Andrew Dunstan
Date:
Subject: Re: Pruning the TODO list