Tom Lane <t...@sss.pgh.pa.us> writes: > Teodor Sigaev <teo...@sigaev.ru> writes: >> I see your point. May be it's better to introduce new system table? >> pg_amorderop >> to store ordering operations for index. > > We could, but that approach doesn't scale to wanting more categories > in the future --- you're essentially decreeing that every new category > of opclass-associated operator will require a new system catalog, > along with all the infrastructure needed for that. That guarantees > that the temptation to take shortcuts will remain high.
On the other hand here's how the fine manual define an operator class: Operator classes are so called because one thing they specify is the set of WHERE-clause operators that can be used with an index (i.e., can be converted into an index-scan qualification). An operator class can also specify some support procedures that are needed by the internal operations of the index method, but do not directly correspond to any WHERE-clause operator that can be used with the index. > If we didn't already have the plus/minus-for-WINDOW-RANGE example > staring us in the face, I might think that an extensible solution > wasn't needed here ... but we do so I think we really need to allow > for multiple categories in some form. Agreed. And we're talking about the basic operators + and -, and about a distance or metric operator. Those remind me of groups and etc. http://en.wikipedia.org/wiki/Group_(mathematics) http://en.wikipedia.org/wiki/Abelian_group http://en.wikipedia.org/wiki/Ring_(mathematics) http://en.wikipedia.org/wiki/Metric_space A group is defined by a data type, an operator (+), and an identity element. If the group is abelian, the given operation is associative and commutative, and each element of the data type has an inverse. Then there's the metric space which is a data type with a distance function. This function must be non-negative, commutative, etc. So I guess what we need here is a Operator Group to define our plus and minus operators, and the fact that it's a group says (by convention, like the total ordering of a BTree) that the + is commutative and the - its opposite. Or we have an "option" called abelian for specifying the commutativity? Then I'm for tricking the maths to say that our notion of a metric space will apply only to our notion of an Operator Group, unless someone really insists on separating the concepts. So an Operator Group defines 2 strategies that you have to attach to your + and - operators, and a support function which is the distance, and optional. Now, we want to have Groups able to work on more than one datatype, for example talking about the distance of a point to a circle or a box. So we need an Operator Group Family, don't we? How much does all that help in this case? -- dim PS: I'm sad to have this discussion after having read it's too late for 9.0. The KNN-Gist stuff with extended ORDER BY indexing was too good to be true. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
