Re: Handling of opckeytype / CREATE OPERATOR CLASS (bug?)

Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> while working on the new BRIN opclasses in [1], I stumbled on something
> I think is actually a bug in how CREATE OPERATOR CLASS handles the
> storage type.

Hm. Both catalogs.sgml and pg_opclass.h say specifically that
opckeytype should be zero if it's to be the same as the input
column type. I don't think just dropping the enforcement of that
is the right answer.

I don't recall for sure what-all might depend on that. I suspect
that it's mostly for the benefit of polymorphic opclasses, so
maybe the right thing is to say that the opckeytype can be
polymorphic if opcintype is, and then we resolve it as per
the usual polymorphism rules.

In any case, it's fairly suspicious that the only opclasses
violating the existing rule are johnny-come-lately BRIN opclasses.

regards, tom lane