Re: Better management of mergejoinable operators
От | Andrew - Supernews |
---|---|
Тема | Re: Better management of mergejoinable operators |
Дата | |
Msg-id | slrnenv4gq.1aj7.andrew+nonews@atlantis.supernews.net обсуждение исходный текст |
Ответ на | Better management of mergejoinable operators (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Better management of mergejoinable operators
|
Список | pgsql-hackers |
On 2006-12-13, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >>>> Right offhand I cannot see a reason why there should be different >>>> equality operators with the same sortops. (If anyone can come up with >>>> a plausible scenario for that, stop me here...) > > BTW, I think it's possible to prove that there need never be two for the > case of both sides the same datatype. If we have a sortop "A < B" on a > single datatype, then its commutator is well defined: "A > B" if and > only if "B < A". And by the trichotomy law, "A = B" must be true in > exactly those cases for which neither "A < B" nor "A > B". So there is > only one possible behavior for an equality operator that is consistent > with the sortop. Counterexample even for a single data type: define an operator x =* y which is true when 2x = y. This is mergejoinable using the following operators: SORT1 = <, SORT2 = <, LTCMP = (2x < y), RTCMP = (2x > y) (which is of course the same sortops as for regular =). The LTCMP and GTCMP operators imply a unique join operator due to trichotomy, but this is not true for the sortops. While the above is a bit contrived, I think non-contrived examples could be found too. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services
В списке pgsql-hackers по дате отправления: