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?)
|
Список | 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 по дате отправления: