From: Tom Lane <tgl@sss.pgh.pa.us>
To: dan-eli@mail.ru
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18742: /src/backend/rewrite/rewriteHandler.c
In-reply-to: <18742-95fbdd0c522076ad@postgresql.org>
References: <18742-95fbdd0c522076ad@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 09 Dec 2024 11:23:51 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3906516.1733759456.1@sss.pgh.pa.us>
Date: Mon, 09 Dec 2024 10:50:56 -0500
Message-ID: <3906517.1733759456@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3906517.1733759456%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.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