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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers