Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c) - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
Date
Msg-id CAKFQuwaZpZ3wicv7=SvS2ZLTofyZD0xV7SNc1zfOZWUqOuy08A@mail.gmail.com
Whole thread Raw
In response to Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
On Fri, Oct 9, 2020 at 6:41 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
The problem is not only in nodeIncrementalSort.c, but in several others too, where people are using TupIsNull with ExecCopySlot.
I would call this a design flaw.
If (TupIsNull)
     ExecCopySlot

The callers, think they are using TupIsNotNullAndEmpty.
If (TupIsNotNullAndEmpty)
     ExecCopySlot

IMO both names are problematic, too data value centric, not semantic.  TupIsValid for the name and negating the existing tests would help to at least clear that part up.  Then, things operating on invalid tuples would be expected to know about both representations.  In the case of ExecCopySlot there is nothing it can do with a null representation of an invalid tuple so it would have to fail if presented one.  An assertion seems sufficient.

David J.

pgsql-hackers by date:

Previous
From: "Hou, Zhijie"
Date:
Subject: Use list_delete_xxxcell O(1) instead of list_delete_ptr O(N) in some places
Next
From: Amit Kapila
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)