Re: GiST Comparing IndexTuples/Datums
От | Tom Lane |
---|---|
Тема | Re: GiST Comparing IndexTuples/Datums |
Дата | |
Msg-id | 23491.1171342507@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | GiST Comparing IndexTuples/Datums ("Matthew Campbell" <mtthw.cmpbll@gmail.com>) |
Ответы |
Re: GiST Comparing IndexTuples/Datums
|
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: