2010/2/14 Tom Lane <tgl@sss.pgh.pa.us>:
> Teodor Sigaev <teodor@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.
>
> 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.
I'm not so familiar with knn gist topic, but I think there are not
enough fundamentals yet. Because we started from defining operators if
they can be "ordered or indexed", general operator semantics is over
them, not adding columns to pg_amop. It will be something like
datatype-independent human word: "add and subtract", "take distance",
"ordered".
And we don't have time to invent such new world.
Regards.
--
Hitoshi Harada
