Re: Potential for bugs while using COPY_POINTER_FIELD to copy NULL pointer - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Potential for bugs while using COPY_POINTER_FIELD to copy NULL pointer
Date
Msg-id 2591.1333979968@sss.pgh.pa.us
Whole thread Raw
In response to Potential for bugs while using COPY_POINTER_FIELD to copy NULL pointer  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> After such a copy tests like if (pointer) will start failing. There are few
> callers of COPY_POINTER_FIELD which do not call the macro if the size can
> be 0. But there are some who do not do so. This looks fishy, in case we
> have if (pointer) kinds of cases.

I don't think we do.  That macro is only used to copy fixed-length
support arrays like sort column numbers.  There would be no reason to
test such a field for null-ness; its size is always determined by other
properties of the node.

It does look like all the actual uses of the macro are protected by
if-tests if the number of columns could be zero (except for MergeJoin
which didn't use to support zero columns but now does; should go fix
that).  But AFAICS that is purely to save a couple of cycles in the copy
operation, not because it would matter later.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: About the behavior of array_length() for empty array
Next
From: Tom Lane
Date:
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)