Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
От | Daniel Gustafsson |
---|---|
Тема | Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL |
Дата | |
Msg-id | 6F44C9AE-50C1-4062-B8E6-0916F63791DD@yesql.se обсуждение исходный текст |
Ответ на | Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL |
Список | pgsql-hackers |
> On 2 Mar 2023, at 15:44, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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. Rebased v3 on top of recent conflicting ICU changes causing the patch to not apply anymore. Also took another look around the tree to see if there were missed callsites but found none new. -- Daniel Gustafsson
Вложения
В списке pgsql-hackers по дате отправления: