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

From Daniel Gustafsson
Subject Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Date
Msg-id 3A966250-443D-4C4D-9398-6ECCEAE2AF5E@yesql.se
Whole thread Raw
In response to Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List 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




pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
Next
From: Jeff Davis
Date:
Subject: Re: Request for comment on setting binary format output per session