Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Date: 2023-03-02 11:05:02
Message-ID: A9444627-45B0-42EC-A131-E77D3FC128DF@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 1 Mar 2023, at 00:20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Also ... at least in assert-enabled builds, maybe we could check that
> the column being fetched this way is actually marked attnotnull?
> That would help to catch misuse.

We could, but that would limit the API to attnotnull columns, rather than when
the caller knows that the attr cannot be NULL either due to attnotnull or due
to intrinsic knowledge based on what is being extracted.

An example of the latter is build_function_result_tupdesc_t() which knows that
proallargtypes cannot be NULL when calling SysCacheGetAttr.

I think I prefer to allow those cases rather than the strict mode where
attnotnull has to be true, do you think it's preferrable to align the API with
attnotnull and keep the current coding for cases like the above?

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2023-03-02 11:32:14 Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Previous Message Peter Eisentraut 2023-03-02 10:54:10 Re: Real config values for bytes needs quotes?