Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Date
Msg-id 1898791.1677768273@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Daniel Gustafsson <daniel@yesql.se>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Next
From: Alexander Korotkov
Date:
Subject: Re: POC: Lock updated tuples in tuple_update() and tuple_delete()