Re: Boolean operators without commutators vs. ALL/ANY

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: Boolean operators without commutators vs. ALL/ANY
Дата
Msg-id 0387426D-D8F6-4391-9F1E-2F9A160CF17D@phlo.org
обсуждение исходный текст
Ответ на Re: Boolean operators without commutators vs. ALL/ANY  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Jun16, 2011, at 21:49 , Tom Lane wrote:
> 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.

What parts of (1) do you think are overkill exactly, then?

> As for #2, what's
> your plan for automatically selecting a commutator operator name?

I figured we'd name it "COMMUTATOR <op>" or something along this line.
That'd mean it'd only be useable with the OPERATOR() syntax, but that's
way better than nothing. Or we could even make the COMMUTATOR argument
mandatory for binary operators returning boolean. After all, if a 
commutator doesn't require a second function, than I fail to see why
you'd ever want to define a predicate without a commutator.

In any case, yeah, (2) is pretty hand-weavy. I included so that we'd
have all the options on the table, not because I think it's particularly
elegant, easy, or interesting to implement (actually, it's probably
none of these).

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

Well, as long as there is some regression test failure for
missing commutators of newly added binary boolean operators, I'm
content.

best regards,
Florian Pflug





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Brar Piening
Дата:
Сообщение: Re: flexible array members