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

On 3/23/21 3:13 AM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.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.
> 

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.

> 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.
> 

I did an experiment - fixed all the opclasses violating the rule by
removing the opckeytype, and ran make checke. The only cases causing
issues were cidr and int4range. Not that it proves anything.

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

Right, that seems suspicious.


regards

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