From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | <emre(at)hasegeli(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pinker *EXTERN* <pinker(at)onet(dot)eu>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Shouldn't "WHEN (OLD.* IS DISTINCT FROM NEW.*)" clause be independent from data type? |
Date: | 2015-10-07 17:52:33 |
Message-ID: | 56155BE1.7070209@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 10/4/15 4:16 AM, Emre Hasegeli wrote:
>> The other line of attack would be to deprecate all the fuzzy comparison
>> behavior in the geometric types, and just make it exact. Don't know how
>> much pain that would add, but surely it would also subtract some.
>
> How can we go forward about this? The current state of the operators
> stand in the way of improving index support for them.
Your easiest way forward right now is probably to create an exact
equality operator for point and the relevant hash opclass. That should
be enough to let IS DISTINCT do it's thing.
BTW, it occurred to me that we could create btree opclasses as well, if
we explicitly compared X before Y (or vice-versa). I certainly wouldn't
call those operators < or >, but maybe there's enough use to supporting
btree for this to make sense.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-10-07 17:55:06 | Re: Try to understand VACUUM and its settings |
Previous Message | Adrian Klaver | 2015-10-07 17:25:16 | Re: postgres standby won't start |