PL/pgSQL: FOUND is NULL, not false, in event trigger functions
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t254391psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 26, 2026 at 11:41 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t254391_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t254391_1 && git checkout t254391_1Patchset v1 (message #1) is on t254391_1
Hi,
plpgsql_exec_function() and plpgsql_exec_trigger() both set the magic
variable FOUND to false before running the function body, but
plpgsql_exec_event_trigger() does not. As a result, FOUND is NULL rather
than
false at the start of a PL/pgSQL event trigger function:
CREATE FUNCTION f() RETURNS event_trigger LANGUAGE plpgsql AS $$
BEGIN RAISE NOTICE 'FOUND is %', FOUND; END $$;
CREATE EVENT TRIGGER t ON ddl_command_start EXECUTE FUNCTION f();
CREATE SCHEMA s;
NOTICE: FOUND is <NULL>
The documentation says that "
*FOUND starts out false within each PL/pgSQLfunction call*" [1]https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS, so this
looks like an oversight. Code such as
"IF NOT FOUND" before any statement has set FOUND would behave differently
in
an event trigger than in any other kind of PL/pgSQL function.
The attached patch fixes this by initializing FOUND to false, as the other
two entry points do, and adds a regression test. The test checks that FOUND
is false on entry to an event trigger function, and that a value set by one
call does not carry over to the next. It fails without the fix.
Since this is a behavior difference from the other function types rather
than
a new feature, I think it could also be back-patched, but I'd like to hear
what others think.
Thanks
[1]: https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS
https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS
--
*Jeevan Chalke*
*Senior Principal Engineer, Engineering Manager*
*Product Development*
enterprisedb.com <https://www.enterprisedb.com>
Jeevan Chalke <jeevan.chalke@enterprisedb.com> writes:
plpgsql_exec_function() and plpgsql_exec_trigger() both set the magic
variable FOUND to false before running the function body, but
plpgsql_exec_event_trigger() does not. As a result, FOUND is NULL rather
than false at the start of a PL/pgSQL event trigger function:
Good catch.
Since this is a behavior difference from the other function types rather
than
a new feature, I think it could also be back-patched, but I'd like to hear
what others think.
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).
It seems unlikely that anyone has written any code that would
be affected by this change, but ...
regards, tom lane
On 26 Oct 2026, at 20:45, Tom Lane <tgl@sss.pgh.pa.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?
--
Daniel Gustafsson
Daniel Gustafsson <daniel@yesql.se> writes:
On 26 Oct 2026, at 20:45, Tom Lane <tgl@sss.pgh.pa.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
On 26 Oct 2026, at 21:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
On 26 Oct 2026, at 20:45, Tom Lane <tgl@sss.pgh.pa.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
Daniel Gustafsson <daniel@yesql.se> writes:
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.
Done that way, then.
regards, tom lane