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
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? |