On 09/17/2015 06:54 AM, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> On 09/17/2015 06:32 AM, Albe Laurenz wrote:
>>> I guess it is dependent on data type as it requires an equality operator,
>>> and type "point" doesn't have one.
>
>> To echo the OP, why is that?
>> http://www.postgresql.org/docs/9.4/interactive/functions-comparison.html
>> For non-null inputs, IS DISTINCT FROM is the same as the <> operator.
>
> Well, that's true: the parser actually looks up the operator named "<>"
> for the given data types, and IS DISTINCT FROM is just a prefilter on
> that to do the right thing with nulls. So because type point has an
> operator that's physically named "<>", that case works.
If you use '<>' explicitly, otherwise:
test=> select '(1,2)'::point is distinct from '(1,3)'::point;
ERROR: operator does not exist: point = point
LINE 1: select '(1,2)'::point is distinct from '(1,3)'::point;
From the docs I would have expected the same behavior as:
test=> select '(1,2)'::point <> '(1,3)'::point;
?column?
----------
t
Is this expected?
If so, should the docs be changed to reflect?
If the docs need changing how does one go about that?
>
> However, in the given case, what gets found for "<>" is record_ne().
> The record comparison functions apply btree comparison functions for
> the individual column datatypes in the record --- and point does not
> have a btree opclass.
Aah, so in the TRIGGER this happen because of the OLD.*, NEW.* record
comparison.
>
> If memory serves, for equal/not-equal comparisons a hash opclass would
> work too, but point does not have that either.
>
> Since type record *does* have btree/hash opclasses, it is not negotiable
> that the component column types obey btree or at least hash semantics.
> The only way to fix this would be to provide such opclasses for point.
> Btree has the probably-fatal obstacle that there's no plausible linear
> sort order for 2-D points. It would be possible to make hash work, if
> it weren't that point_eq() is fuzzy equality not exact equality.
>
> regards, tom lane
>
--
Adrian Klaver
adrian.klaver@aklaver.com