Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
От | Daniel Gustafsson |
---|---|
Тема | Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL |
Дата | |
Msg-id | A9444627-45B0-42EC-A131-E77D3FC128DF@yesql.se обсуждение исходный текст |
Ответ на | Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
|
Список | pgsql-hackers |
> On 1 Mar 2023, at 00:20, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: