MIME-Version: 1.0
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>
In-Reply-To: <4984118e-0dc5-49a9-b279-fd0b707be8e0@eisentraut.org>
From: Paul A Jungwirth <pj@illuminatedcomputing.com>
Date: Thu, 2 Jul 2026 07:29:03 -0700
Message-ID: 
 <CA+renyUkKaWtWZX2UcojKVjM=f1F5kgdvR8Pr5QqyJqqe_dw-g@mail.gmail.com>
Subject: Re: [PATCH] Fix null pointer dereference in PG19
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Aleksander Alekseev <aleksander@tigerdata.com>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BrenyUkKaWtWZX2UcojKVjM%3Df1F5kgdvR8Pr5QqyJqqe_dw-g%40mail.gmail.com>
Precedence: bulk

On Thu, Jul 2, 2026 at 12:25=E2=80=AFAM Peter Eisentraut <peter@eisentraut.=
org> wrote:
>
> > But I don't mind holding it back if that's what people want to do.
> > Looking more closely at INSTEAD OF triggers, I found another bug: the
> > FOR PORTION OF qual (and TLE) were not added, so the trigger would
> > fire on more rows than it should, and NEW.valid_at was not
> > pre-computed. The second patch here fixes that. I'll defer to others
> > whether we should fix the INSTEAD OF interaction now or wait 'til v20.
>
> It seems to me that both FOR PORTION OF and INSTEAD OF triggers are SQL
> standard features, so this discussion should refer to what the standard
> says, and possibly consider what other implementations do (in addition
> to discussing what makes sense).  Since that hasn't been done yet, maybe
> prohibiting this combination for now, as proposed by Aleksander, would
> be best.

Okay, let's do that. I'll do some research to see what the standard
says and whether any other RDBMS offers guidance.

Yours,

--=20
Paul              ~{:-)
pj@illuminatedcomputing.com