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
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 |