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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Handling of opckeytype / CREATE OPERATOR CLASS (bug?)
Дата
Msg-id 810842.1616465623@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Handling of opckeytype / CREATE OPERATOR CLASS (bug?)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: Handling of opckeytype / CREATE OPERATOR CLASS (bug?)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: "kuroda.hayato@fujitsu.com"
Дата:
Сообщение: RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Key management with tests