Search Postgresql Archives

Re: Shouldn't "WHEN (OLD.* IS DISTINCT FROM NEW.*)" clause be independent from data type?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/17/2015 06:54 AM, Tom Lane wrote:
Adrian Klaver <adrian.klaver@xxxxxxxxxxx> 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@xxxxxxxxxxx


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux