Re: GiST Comparing IndexTuples/Datums

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Matthew Campbell" <mtthw(dot)cmpbll(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: GiST Comparing IndexTuples/Datums
Date: 2007-02-13 04:55:07
Message-ID: 23491.1171342507@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Matthew Campbell" <mtthw(dot)cmpbll(at)gmail(dot)com> writes:
> I've been working with a group trying to
> implement UNIQUE index functionality in GiST
> ... but we can't figure out how to
> compare the two datums then. The actual data type of the value being
> inserted would be different depending on the type of column you created the
> index on. Since you provide an opclass when creating a gist index, are we
> supposed to use one of the user defined functions to compare items?

Yes; otherwise you have no datatype independence, not to mention that
different opclasses could legitimately have different definitions of
equality for the same datatype. (Ye olde standard example is a
complex-number datatype with a sort-by-real-part opclass and a
sort-by-absolute-value opclass.)

I think the missing link here is that you'd need some convention for
having the opclass identify which of its functions/operators is an
equality check --- or perhaps even more to the point, having a way for
it to identify whether it supports equality at all. It doesn't seem
unreasonable to me to legislate that if a GiST opclass supports unique
indexes, then it must use operator number so-and-so for equality. But
there are lots of GiST opclasses that don't include equality at all; we
can't break that case.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Kahwe Smith 2007-02-13 06:17:12 Re: OT: IRC nick to real world mapping
Previous Message Tom Lane 2007-02-13 04:19:14 Re: Variable length varlena headers redux