Re: PL/pgSQL: FOUND is NULL, not false, in event trigger functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PL/pgSQL: FOUND is NULL, not false, in event trigger functions
Date: 2026-10-26 20:22:24
Message-ID: 742751.1793046144@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 26 Oct 2026, at 20:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Given the lack of field complaints, I'm inclined to leave it as-is
>> in released branches (maybe it's not too late for v19, though).

> If we're leaving it as-is in backbranches, wouldn't it be better to opt for
> consistency and leave it in 19 as well and only adjust the documentation?

I don't particularly want to document the broken behavior (especially
if we'd have to further document that it will change in v20). That
would just contribute to user confusion. If you want docs to match
code I'd rather back-patch the code change.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2026-10-26 20:24:53 nbtree: opt-in leaf key prefix compression
Previous Message Dongpo Liu 2026-10-26 20:13:30 Re: pg_*_advice: tsv load failure, etc.