Re: Explicit NULL dereference (src/backend/utils/adt/ruleutils.c) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Explicit NULL dereference (src/backend/utils/adt/ruleutils.c)
Date
Msg-id 740257.1604346590@sss.pgh.pa.us
Whole thread Raw
In response to Re: Explicit NULL dereference (src/backend/utils/adt/ruleutils.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Explicit NULL dereference (src/backend/utils/adt/ruleutils.c)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Ranier Vilela <ranier.vf@gmail.com> writes:
> Em seg., 2 de nov. de 2020 às 01:36, Kyotaro Horiguchi <
> horikyota.ntt@gmail.com> escreveu:
>> Doesn't seem that ev_qual and ev_action can be NULL.  The same
>> function in the current converts action list to string using
>> nodeToSTring so NIL is converted into '<>', which is not NULL.

> I think that Assert is not the right solution here.

I think there's some confusion here: whether the ev_actions column can
contain a SQL NULL is a very different thing from whether the result of
stringToNode() on it can be a NIL list.  The latter should also not
happen, but it's not enforced by low-level code in the same way that
the NOT NULL property is.  So in my judgment, it's okay for us to just
Assert that we got a not-null datum, but it's probably worth expending
an actual test-and-elog for the NIL-list case.

Of course, someone could put a string into that column that doesn't
read out as a List at all, or it does but the elements aren't Query
nodes, etc etc.  There's a very finite limit to how much code I'm
willing to expend on such scenarios.  But a test for NIL list seems
reasonable, since this function previously had what looked like sane
handling for that case.

Anyway, I adjusted Kyotaro-san's patch a bit (including fixing the
near identical code in make_viewdef) and pushed it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: how to replicate test results in cf-bot on travis
Next
From: Andres Freund
Date:
Subject: Re: libpq compression