"Matthew Campbell" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings