Re: COMMUTATOR doesn't seem to work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "D'Arcy Cain" <darcy(at)druid(dot)net>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: COMMUTATOR doesn't seem to work
Date: 2012-06-22 15:36:02
Message-ID: 12292.1340379362@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"D'Arcy Cain" <darcy(at)druid(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-06-22 15:38:22 Re: Pruning the TODO list
Previous Message Robert Haas 2012-06-22 15:29:18 Re: Allow WAL information to recover corrupted pg_controldata