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

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

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