Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

On 4/12/21 6:55 PM, Ranier Vilela wrote:
>
>
> Em seg., 12 de abr. de 2021 às 03:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> escreveu:
>
> Michael Paquier <michael(at)paquier(dot)xyz <mailto:michael(at)paquier(dot)xyz>>
> writes:
> > On Sun, Apr 11, 2021 at 07:42:20PM -0300, Ranier Vilela wrote:
> >> Em dom., 11 de abr. de 2021 às 16:25, Justin Pryzby
> <pryzby(at)telsasoft(dot)com <mailto:pryzby(at)telsasoft(dot)com>>
> >>> I think it's cleanest to write:
> >>> |HeapTupleData tmptup = {0};
>
> > I agree that this would be cleaner.
>
> It would be wrong, though, or at least not have the same effect.
>
> I think that you speak about fill pointers with 0 is not the same as
> fill pointers with NULL.
>  
>
> ItemPointerSetInvalid does not set the target to all-zeroes.
>
> ItemPointerSetInvalid set or not set the target to all-zeroes?
>

Not sure what exactly are you asking about? What Tom said is that if you
do 'struct = {0}' it sets all fields to 0, but we only want/need to set
the t_self/t_tableOid fields to 0.

>
> (Regardless of that detail, it's generally best to accomplish
> objective X in the same way that existing code does.  Deciding
> that you have a better way is often wrong, and even if you
> are right, you should then submit a patch to change all the
> existing cases.)
>
> I was confused here, does the patch follow the pattern and fix the
> problem or not?
>

I believe it does, and it's doing it in the same way as most other
similar places.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company