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

On 3/23/21 6:15 AM, Tom Lane wrote:
> 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.
>

That's possible. I'm not familiar with how we deal with polymorphic
opclasses etc. but I tried to look for places dealing with opckeytype,
so that I can compare BRIN vs. the other AMs, but the only references
seem to be in amvalidate() functions.

So either the difference is not very obvious, or maybe the other AMs
don't trigger this for some reason. For example btree has a separate
opclass for cidr, so it does not have to use "inet_ops" as polymorphic.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company