Re: Boolean operators without commutators vs. ALL/ANY

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: Boolean operators without commutators vs. ALL/ANY
Дата
Msg-id DD43D7CD-747F-45E1-BF11-0429EDFA3B32@phlo.org
обсуждение исходный текст
Ответ на Re: Boolean operators without commutators vs. ALL/ANY  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Boolean operators without commutators vs. ALL/ANY
Re: Boolean operators without commutators vs. ALL/ANY
Список 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 по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: proposal: a validator for configuration files
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: WIP: Fast GiST index build