Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-03-25T22:10:46Z
Lists: pgsql-hackers
> On 14 Mar 2023, at 08:00, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:

> I prefer to use "null value" for SQL null values, and NULL for the C symbol.

Thats a fair point, I agree with that.

> I'm a bit hesitant about hardcoding pg_catalog here.  That happens to be true, of course, but isn't actually enforced, I think.  I think that could be left off.  It's not like people will be confused about which schema "pg_class.relname" is in.
> 
> Also, the cached tuple isn't really for the attribute, so maybe split that up a bit, like
> 
> "unexpected null value in cached tuple for catalog %s column %s"

No objections, so changed to that wording.

With these changes and a pgindent run across it per Davids comment downthread,
I've pushed this now.  Thanks for review!

I'm keeping a watchful eye on the buildfarm; francolin has errored in
recoveryCheck which I'm looking into but at first glance I don't think it's
related (other animals have since passed it and it works locally, but I'll keep
digging at it to make sure).

--
Daniel Gustafsson




Commits

  1. Add SysCacheGetAttrNotNull for guaranteed not-null attrs