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
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 |