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

Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> On 3/23/21 3:13 AM, Tom Lane wrote:
>> 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.

> Yeah, that's possible. I was mostly just demonstrating the difference in
> behavior. Maybe the right fix is to fix the catalog contents and then
> tweak the AM code, or something.

Digging in our git history, the rule about zero opckeytype dates to
2001 (f933766ba), which precedes our invention of polymorphic types
in 2003 (somewhere around 730840c9b). So I'm pretty sure that that
was a poor man's substitute for polymorphic opclasses, which we
failed to clean up entirely after we got real polymorphic opclasses.

Now, I'd be in favor of cleaning that up and just using standard
polymorphism rules throughout. But (without having studied the code)
it looks like the immediate issue is that something in the BRIN code is
unfamiliar with the rule for zero opckeytype. It might be a noticeably
smaller patch to fix that than to get rid of the convention about zero.

regards, tom lane