| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c) |
| Date: | 2020-10-10 03:10:49 |
| Message-ID: | CAKFQuwaZpZ3wicv7=SvS2ZLTofyZD0xV7SNc1zfOZWUqOuy08A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 9, 2020 at 6:41 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-10-10 04:32:46 | Re: Parallel INSERT (INTO ... SELECT ...) |
| Previous Message | Hou, Zhijie | 2020-10-10 02:44:49 | Use list_delete_xxxcell O(1) instead of list_delete_ptr O(N) in some places |