| 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
| 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 |