Re: Handling of opckeytype / CREATE OPERATOR CLASS (bug?) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Handling of opckeytype / CREATE OPERATOR CLASS (bug?)
Date
Msg-id 810842.1616465623@sss.pgh.pa.us
Whole thread Raw
In response to Handling of opckeytype / CREATE OPERATOR CLASS (bug?)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: Handling of opckeytype / CREATE OPERATOR CLASS (bug?)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
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.

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



pgsql-hackers by date:

Previous
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Next
From: Bruce Momjian
Date:
Subject: Re: Key management with tests