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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:32:41
Message-ID: 11B03A20-BD4E-43EC-827D-499727FA9211@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 26 Oct 2026, at 21:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.

Ah, I misread and thought you were advocating for what you clearly wanted to
avoid. Given the lack of complaints then +1 for at most fixing in 19.
Backpatching takes a non-trivial amount of time, which really isn't a commodity
we have plenty of.

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-10-26 20:40:51 Re: Do we need an index on pg_constraint.confrelid?
Previous Message Greg Burd 2026-10-26 20:24:53 nbtree: opt-in leaf key prefix compression