Re: Custom Operators Cannot be Found for Composite Type Values - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Custom Operators Cannot be Found for Composite Type Values
Date
Msg-id 740.1331180625@sss.pgh.pa.us
Whole thread Raw
In response to Custom Operators Cannot be Found for Composite Type Values  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: Custom Operators Cannot be Found for Composite Type Values  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
"David E. Wheeler" <david@justatheory.com> writes:
> I�m doing some development with the new JSON type (actually, Andrew�s backport to 9.1) and needed to do some very
basicequivalence testing. So I created a custom operator:
 

>     CREATE OR REPLACE FUNCTION json_eq(
>         json,
>         json
>     ) RETURNS BOOLEAN LANGUAGE SQL STRICT IMMUTABLE AS $$
>         SELECT $1::text = $2::text;
>     $$;

>     CREATE OPERATOR = (
>         LEFTARG   = json,
>         RIGHTARG  = json,
>         PROCEDURE = json_eq
>     );

> With this in place, these work:

>      SELECT '{}'::json = '{}'::json;
>      SELECT ROW('{}'::json) = ROW('{}'::json);

> However this does not:

>     create type ajson AS (a json);
>     SELECT ROW('{}'::json)::ajson = ROW('{}'::json)::ajson;

> That last line emits an error:

>     ERROR:  could not identify an equality operator for type json

> To which my response was: WTF?

You have not told the system that your operator is equality for the
datatype.  It's just a random operator that happens to be named "=".
We try to avoid depending on operator names as cues to semantics.

You need to incorporate it into a default hash or btree opclass before
the composite-type logic will accept it as the thing to use for
comparing that column.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch: improve selectivity estimation for IN/NOT IN
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade --logfile option documentation