Re: Change pfree to accept NULL argument

David Rowley <dgrowleyml@gmail.com>

From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-08-24T12:14:16Z
Lists: pgsql-hackers
On Wed, 24 Aug 2022 at 23:07, David Rowley <dgrowleyml@gmail.com> wrote:
> One counter argument to that is for cases like list_free_deep().
> Right now if I'm not mistaken there's a bug (which I just noticed) in
> list_free_private() that would trigger if you have a List of Lists and
> one of the inner Lists is NIL.  The code in list_free_private() just
> seems to go off and pfree() whatever is stored in the element, which I
> think would crash if it found a NIL List.  If pfree() was to handle
> NULLs at least that wouldn't have been a crash, but in reality, we
> should probably fix that with recursion if we detect the element IsA
> List type. If we don't use recursion, then the "free" does not seem
> very "deep". (Or maybe it's too late to make it go deeper as it might
> break existing code.)

Hmm, that was a false alarm. It seems list_free_deep() can't really
handle freeing sublists as the list elements might be non-Node types,
which of course have no node tag, so we can't check for sub-Lists.

David



Commits

  1. Add more detail why repalloc and pfree do not accept NULL pointers

  2. Remove unneeded null pointer checks before PQfreemem()

  3. Remove unnecessary casts in free() and pfree()