Feedback-ID: ie0a040ee:Fastmail
Message-ID: <391a2845-105b-4048-a113-835c2742fea1@eisentraut.org>
Date: Mon, 6 Jul 2026 08:34:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Fix null pointer dereference in PG19
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Cc: Aleksander Alekseev <aleksander@tigerdata.com>,
 PostgreSQL Development <pgsql-hackers@postgresql.org>
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>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: 
 <CA+renyUkKaWtWZX2UcojKVjM=f1F5kgdvR8Pr5QqyJqqe_dw-g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/391a2845-105b-4048-a113-835c2742fea1%40eisentraut.org>
Precedence: bulk

On 02.07.26 16:29, Paul A Jungwirth wrote:
> On Thu, Jul 2, 2026 at 12:25 AM 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.

Do we have a suitable patch for that?

The patch proposed at the top of this thread checks for the presence of 
triggers at parse time, which, I think, again has the problem that the 
presence of triggers could change between parse and execution time.