Re: BUG #18742: /src/backend/rewrite/rewriteHandler.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dan-eli(at)mail(dot)ru
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18742: /src/backend/rewrite/rewriteHandler.c
Date: 2024-12-09 15:50:56
Message-ID: 3906517.1733759456@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> Deref of view->rd_rules->numLocks takes place without checking
> view->rd_rules for NULL. The check rel->rd_rules for NULL above leaves an
> opportunity for calling get_view_query() function. During the initialization
> and execution rd_rules field of Relation structure is NULL.

The preceding "Assert(view->rd_rel->relkind == RELKIND_VIEW)"
should provide sufficient assurance that the Relation has
an rd_rules entry. If it does not, well, the ensuing core dump
would have about the same result as "Assert(view->rd_rules != NULL)".
So I feel no need to add any additional checks there.

The short answer is that it's caller error if this function is
executed on a non-view, and there is no reason to believe that
any such bug exists. This sort of microscopic analysis that
doesn't take things like that into account isn't terribly useful.
(Of course, if you can demonstrate a real case whereby this is
reached, that would be interesting.)

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Artur Zakirov 2024-12-09 15:54:47 pg_dump crash on identity sequence with not loaded attributes
Previous Message Alvaro Herrera 2024-12-09 14:33:28 Re: BUG #18746: /src/backend/parser/parse_utilcmd.c