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 по дате отправления: