Re: Hashable custom types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hashable custom types
Date: 2015-07-08 20:31:42
Message-ID: 13110.1436387502@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> On Fri, Apr 25, 2014 at 4:54 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> On Fri, Apr 25, 2014 at 4:47 PM, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> wrote:
>>> Is it possible to make custom types hashable? There's no hook in the
>>> CREATE TYPE call for a hash function, but can one be hooked up
>>> somewhere else? In an operator?

>> See 35.14.6., System Dependencies on Operator Classes

> Coming back to this, I created an appropriate opclass...

> CREATE OR REPLACE FUNCTION geometry_hash_eq(geom1 geometry, geom2 geometry)
> RETURNS boolean
> AS '$libdir/postgis-2.2', 'lwgeom_hash_eq'
> LANGUAGE 'c' IMMUTABLE STRICT;

Why are you creating a separate equality operator, rather than just using
the type's existing equality operator (I assume it's got one) in the
hash opclass?

> It still says I lack the secret sauce...

> ERROR: could not implement recursive UNION
> DETAIL: All column datatypes must be hashable.

UNION will preferentially glom onto the btree equality operator, if memory
serves. If that isn't also the hash equality operator, things won't work
pleasantly.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Ramsey 2015-07-08 20:33:50 Re: Hashable custom types
Previous Message Paul Ramsey 2015-07-08 20:12:30 Re: Hashable custom types