Re: New data type: uniqueidentifier

From: "Dmitry G(dot) Mastrukov" <dmitry(at)taurussoft(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New data type: uniqueidentifier
Date: 2001-06-29 01:48:19
Message-ID: 001101c1003d$931ad9a0$016ba8c0@taurussoft.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Dmitry G. Mastrukov" <dmitry(at)taurussoft(dot)org> writes:
> > Alex Pilosov <alex(at)pilosoft(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2001-06-29 13:20:47 Configuration of statistical views
Previous Message Mike Cianflone 2001-06-29 01:16:58 Order of triggers