Re: Boolean operators without commutators vs. ALL/ANY - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: Boolean operators without commutators vs. ALL/ANY
Date
Msg-id DD43D7CD-747F-45E1-BF11-0429EDFA3B32@phlo.org
Whole thread Raw
In response to Re: Boolean operators without commutators vs. ALL/ANY  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Boolean operators without commutators vs. ALL/ANY
Re: Boolean operators without commutators vs. ALL/ANY
List pgsql-hackers
On Jun16, 2011, at 19:54 , Robert Haas wrote:
> On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We deprecated those names for the geometric operators largely because
>> there wasn't any visual correlation between the commutator pairs.
>> I can't see introducing the same pairing for regex operators if we
>> already decided the geometric case was a bad idea.
> 
> I'm having trouble avoiding the conclusion that we're trying to shove
> a round peg into a square hole.  The idea that we have to have a
> commutator for every operator just because we don't handle left and
> right symmetrically sits poorly with me.  I can't really argue with
> your statement that it's the easiest way to address Florian's gripe,
> but because it almost surely is.  But it still feels like a kludge.

Well, I think there are basically three choices here, kludge or no
kludge.

(1) We either decree once and for all that binary operations ought to
have commutators, modify CREATE TYPE to issue a warning if you
create one without, add the missing ones, and add a check for
that to opr_sanity (possibly excluding some deprecated operators).

or

(2) We arrange for commutators of binary operators to be created
automatically. 

or

(3) Or we bit the bullet and provide something similar to
"ANY/ALL op scalar". We do have the liberty to pick whatever syntax we
feel comfortable with, though, since we're out of SQL standard territory
anyway.

What I *wouldn't* like us to is just a few missing commutators and be
done with it. That pretty much guarantees that this issue will pop up
again some time in the future.

I personally prefer (3), but would also be content with (1), and be
ready to provide a patch for that. To be fair, (1) really doesn't seem
that kludgy if one takes into account that all indexable operators must
have commutators anyway.

I haven't checked how viable (2) actually is, but I dare say that it's
probably quite a bit of work. Essentially, we'd need a way to automatically
swap a function's argument before invoking the function, which I'm not
sure that fmgr can cleanly be persuaded to do.

Now all that's required is to agree on a way forward ;-)

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: proposal: a validator for configuration files
Next
From: Heikki Linnakangas
Date:
Subject: Re: WIP: Fast GiST index build