Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Дата
Msg-id 1898791.1677768273@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> I think an error message like
>      "unexpected null value in system cache %d column %d"
> is sufficient.  Since these are "can't happen" errors, we don't need to 
> spend too much extra effort to make it prettier.

I'd at least like to see it give the catalog's OID.  That's easily
convertible to a name, and it doesn't tend to move around across PG
versions, neither of which are true for syscache IDs.

Also, I'm fairly unconvinced that it's a "can't happen" --- this
would be very likely to fire as a result of catalog corruption,
so it would be good if it's at least minimally interpretable
by a non-expert.  Given that we'll now have just one copy of the
code, ISTM there's a good case for doing the small extra work
to report catalog and column by name.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: POC: Lock updated tuples in tuple_update() and tuple_delete()