Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
От | Ranier Vilela |
---|---|
Тема | Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c) |
Дата | |
Msg-id | CAEudQArQaWUrRXgz7yvMb9QwQz5B7-x_ZDtQYF4VFADvq+SnsA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c) ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
|
Список | pgsql-hackers |
Em sáb., 10 de out. de 2020 às 00:11, David G. Johnston <david.g.johnston@gmail.com> escreveu:
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)
ExecCopySlotIMO 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.
IHMO, assertion it is not the solution.
Steven suggested looking for some NULL pointer font above the calls.
I say that it is not necessary, there is no NULL pointer.
Whoever guarantees this is the combination, which for me is an assertion.
If (TupIsNull)
ExecCopySlot
It works as a subject, but in release mode.
It is the equivalent of:
If (TupIsNull)
Abort
The only problem for me is that we are running this assertion on the clients' machines.
regards,
Ranier Vilela
В списке pgsql-hackers по дате отправления: