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.
Now on the flip side, adding new catalogs would allow flexibility to
add columns that aren't there in pg_amop, which could come in handy
if some future category requires auxiliary data that's not needed for
the existing category of index search operators. But since the two
examples we have at hand don't appear to need any extra data, this
argument isn't real strong.
regards, tom lane
