Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Дата
Msg-id 689af245-3dec-b5ee-c62c-cc33e2d19c90@enterprisedb.com
обсуждение исходный текст
Ответ на Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 28.02.23 21:14, Daniel Gustafsson wrote:
> Today we have two fairly common patterns around extracting an attr from a
> cached tuple:
> 
>    a = SysCacheGetAttr(OID, tuple, Anum_pg_foo_bar, &isnull);
>    Assert(!isnull);
> 
>    a = SysCacheGetAttr(OID, tuple, Anum_pg_foo_bar, &isnull);
>    if (isnull)
>      elog(ERROR, "..");

> The attached refactoring introduce SysCacheGetAttrNotNull as a wrapper around
> SysCacheGetAttr where a NULL value triggers an elog().  This removes a lot of
> boilerplate error handling which IMO leads to increased readability as the
> error handling *in these cases* don't add much (there are other cases where
> checking isnull does a lot of valuable work of course).  Personally I much
> prefer the error-out automatically style of APIs like how palloc saves a ton of
> checking the returned allocation for null, this aims at providing a similar
> abstraction.

Yes please!

I have occasionally wondered whether just passing the isnull argument as 
NULL would be sufficient, so we don't need a new function.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jelte Fennema
Дата:
Сообщение: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
Следующее
От: "Gregory Stark (as CFM)"
Дата:
Сообщение: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel