Re: New data type: uniqueidentifier
Dmitry G. Mastrukov <dmitry@taurussoft.org>
From: "Dmitry G. Mastrukov" <dmitry@taurussoft.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgresql.org>
Date: 2001-06-29T01:48:19Z
Lists: pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Dmitry G. Mastrukov" <dmitry@taurussoft.org> writes: > > Alex Pilosov <alex@pilosoft.com> wrote: > >> On Tue, 26 Jun 2001, Dmitry G. Mastrukov wrote: > > I've marked "=" operator with HASH clause (and planner has started to > > use > > hash jons). But as I understand the right way is to create special hash > > function (may be wrapper for hash_any(), isn't it?) and register it for > > hash > > as for btree method. > >> > >> No. Currently, there's no way to specify a hash function for a given > >> operator, it always uses a builtin function that operates on memory > >> representation of a value. > > > Strange. When I execute following query (slightly modified query from User's > > Guide chapter 7.6) > > You're looking at support for hash indexes, which have nothing to do > with hash joins. > > *Why* they have nothing to do with hash joins, I dunno. You'd think > that using the same hash functions for both would be a good idea. > But that's not how it's set up at the moment. > OK. It's clear for me now. Thanks. But should I create support for hash indexes? Since builtin types have such support I want it too for uniqueidentifier :) How can I make it? regards, Dmitry