| From: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | PL/pgSQL: FOUND is NULL, not false, in event trigger functions |
| Date: | 2026-10-26 11:27:25 |
| Message-ID: | CAM2+6=U_=hZmgs1v1JJ-XJk2bpbfqQPP9MNRDbp5RoEsOW8xsQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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], 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
--
*Jeevan Chalke*
*Senior Principal Engineer, Engineering Manager*
*Product Development*
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Initialize-FOUND-to-false-in-PL-pgSQL-event-trigg.patch | application/octet-stream | 4.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2026-10-26 11:28:18 | Re: SERIALIZABLE can commit write skew after SSI summarization |
| Previous Message | David Steele | 2026-10-26 10:40:07 | Re: Avoid truncated or zero-padded copies of replaced files in backups. |