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
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 |