Re: Boolean operators without commutators vs. ALL/ANY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Boolean operators without commutators vs. ALL/ANY
Date: 2011-06-16 19:49:16
Message-ID: 8526.1308253756@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(at)phlo(dot)org> writes:
> 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.

All three of these are massive overkill. What we need is a general
policy that providing commutators is a good idea. We do not need to try
to make it 100.00% with an enforcement mechanism. As for #2, what's
your plan for automatically selecting a commutator operator name?

(Having said that, I *was* thinking of adding an opr_sanity test ... but
not expecting that we'd get it to find zero rows.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-06-16 19:49:45 Re: flexible array members
Previous Message Pavel Stehule 2011-06-16 19:46:16 Re: Nested CASE-WHEN scoping