Re: pgsql: Cache by-reference missing values in a long lived context

On 2023-08-24 Th 16:57, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> On 2023-08-24 Th 11:27, Tom Lane wrote:
>>> The v11 version of this patch is causing a compiler warning for me:
>> Sorry about that, fixed.
> Thanks!
>
>> While we're about it, let's also fix these warnings which are seen on my
>> systems building releases 11 and 12:
>> /home/andrew/bf/root/REL_11_STABLE/pgsql.build/../pgsql/src/backend/commands/foreigncmds.c:481:22:
>> warning: ‘funcargtypes’ may be used uninitialized [-Wmaybe-uninitialized]
>> /home/andrew/bf/root/REL_12_STABLE/pgsql.build/../pgsql/src/backend/commands/foreigncmds.c:487:22:
>> warning: ‘funcargtypes’ may be used uninitialized [-Wmaybe-uninitialized]
>> Maybe funcargtypes here should be initialized to { 0 } ?
> Hm. It looks like we got rid of those warnings in v13 via dcb7d3caf:
>
> Author: Alvaro Herrera<alvherre(at)alvh(dot)no-ip(dot)org>
> Branch: master Release: REL_13_BR [dcb7d3caf] 2019-11-12 17:06:58 -0300
>
> Have LookupFuncName accept NULL argtypes for 0 args
>
> I'm a little tempted to propose that a better solution is to
> back-patch that patch. Removing the warning alone doesn't make
> a very strong case for that, but there are other arguments:
>
> * Somebody might back-patch code relying on the newer convention;
>
> * All else being equal, it's better to keep the code in different
> branches looking similar.
>
> I'm not sure if those arguments justify a back-patch instead of
> the localized hack you suggest.
>
>

Seems like overkill given the age of the surrounding code and the
nearness to EOL of releases 11 and 12.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com