"Matthew Campbell" <mtthw.cmpbll@gmail.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
