Re: Boolean operators without commutators vs. ALL/ANY

On Thu, Jun 16, 2011 at 2:22 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On Jun16, 2011, at 19:54 , Robert Haas wrote:
>> On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 ;-)

Well, Tom seems pretty strongly in favor of #1, or some variant of it,
and while I don't find that to be enormously elegant it does have the
virtue of being quite a bit less work than any of the other options.
I think the chances of that being a complete and permanent solution
are less than 50%, but perhaps it's close enough for government work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company