Re: Simplifying pg_am representation of index sortability

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> You have operators like "contains" and "is contained by" which would be
> opposites of eachother, but could never be used in a b-tree class.

A quick count shows that 46% of the entries in pg_operator that have an
oprcom link are not in any btree opclass. For oprnegate the figure is a
bit lower (29%), but in any case getting rid of these columns would lose
a whole lot of information.

The specific reason that we have to have oprcom in particular is that
large parts of the executor want operators expressed the "right way
around": indexscan constraints have to be "indexcol op something" not
vice versa, merge and hash conditions have to be "outervar op innervar".
We could probably deduce what we need for merge and hash from the
opclasses (since those depend on the operators to be in btree and hash
classes respectively), but for indexes this would mean understanding the
operator interrelationships for every AM not only btree. And I don't
think that's even possible for GIST or GIN because of their flexible
operator strategy numbering.

As for oprnegate, we'd lose the basic fact that = and <> are negators
because <> isn't a btree-indexable operator ...

regards, tom lane