Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize
Дата
Msg-id CAApHDvpW3ZEyTyogjD6qJsnuTFujLk3yTyCPX-to7VhftkrakQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize  (Alexander Lakhin <exclusion@gmail.com>)
Список pgsql-bugs
On Fri, 26 Apr 2024 at 03:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I do not like testing "atttypid == NAMEOID" one bit.  As noted,
> that will fail on domains over name.  It will also result in
> unnecessary work when reading non-btree indexes that contain
> name, since I don't think anything else has the same hack
> that btree name_ops does (grep for cstring in pg_opclass.dat).
> I think the correct thing is to see whether the index opclass
> for the column is btree name_ops.  We don't seem to have an
> oid_symbol macro for that, but it shouldn't be hard to add,
> at least in HEAD.

On looking at the relcache code, I don't see anywhere that we store
the opclass Oid in RelationData. IndexSupportInitialize() only records
the opcfamily and opcintype. Assuming we can't add new fields to
RelationData in the backbranches, is there a reason why we can't check
for rd_opfamily of TEXT_BTREE_FAM_OID and rd_opcintype of NAMEOID?

I've attached an updated patch that does it that way and also did a
round of commenting the code.

David

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
Следующее
От: "Javali, Pramod"
Дата:
Сообщение: Unable to connect to server