From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
cc: Peter Eisentraut <peter@eisentraut.org>,
        Aleksander Alekseev <aleksander@tigerdata.com>,
        PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Fix null pointer dereference in PG19
In-reply-to: 
 <CA+renyXPEJYOVov3XtzTp3NusGkObc9UeW-Nm78K8_nsWSnnfg@mail.gmail.com>
References: 
 <CAJ7c6TME+ix6VRf-2TPnVTsj8qn_hy6sYAOmMhZEivwsu2wS6g@mail.gmail.com>
 <626986.1776785090@sss.pgh.pa.us>
 <CACJufxFgKVL=NnPocAwhRFqpLHckN3N1Ndf7FjGNTdtsAA26mg@mail.gmail.com>
 <CA+renyW52FJ=+pnh+N_xqjUev_MNUCk_mgD2UC7UT0jyAHCE8Q@mail.gmail.com>
 <84f20d0d-3bc8-4843-bd7e-21bce20f8582@eisentraut.org>
 <CAJ7c6TO+kTwk5MBayLARxsPk-YCsDt2QH9P_PeTYoc3zPYCS3Q@mail.gmail.com>
 <CA+renyU6UZnpkgAuog0BVhqyD=G+_UVLzN2Ccpt2sV-qkF-_VQ@mail.gmail.com>
 <CAJ7c6TN7dekEHU8Vu4jV5+Zq7h2cVZQgwkYFCrU0jrjT26-ANw@mail.gmail.com>
 <CA+renyXs5mkPb-Vg=uF2Hj0jP2ufutc1_Eht=eb3+b_WpjiqLg@mail.gmail.com>
 <4984118e-0dc5-49a9-b279-fd0b707be8e0@eisentraut.org>
 <CA+renyUkKaWtWZX2UcojKVjM=f1F5kgdvR8Pr5QqyJqqe_dw-g@mail.gmail.com>
 <391a2845-105b-4048-a113-835c2742fea1@eisentraut.org>
 <CA+renyXPEJYOVov3XtzTp3NusGkObc9UeW-Nm78K8_nsWSnnfg@mail.gmail.com>
Comments: In-reply-to Paul A Jungwirth <pj@illuminatedcomputing.com>
	message dated "Tue, 07 Jul 2026 18:45:46 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1894791.1783476457.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 07 Jul 2026 22:07:37 -0400
Message-ID: <1894792.1783476457@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1894792.1783476457%40sss.pgh.pa.us>
Precedence: bulk

Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> On Tue, Apr 21, 2026 at 8:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Checking this at parse time is completely the wrong thing.
>> The view could have gained (or lost) triggers by the time
>> it's executed.

> But INSTEAD OF triggers are selected in the rewriter, which uses the
> same relcache snapshot as parse analysis. And a concurrent change
> can't sneak in different triggers, because that causes a relcache
> invalidation, so we redo the parse & rewrite phases.

You have forgotten about views and rewrite rules.  Those go to disk in
post-parser form, and will be rewritten only at execution sometime
later, *without* a re-parse.

			regards, tom lane