The function hash table keys made by compute_function_hashkey() failed
to distinguish event-trigger call context from regular call context.
This meant that once we'd successfully made a hash entry for an event
trigger (either by validation, or by normal use as an event trigger),
an attempt to call the trigger function as a plain function would
find this hash entry and thereby bypass the you-can't-do-that check in
do_compile(). Thus we'd attempt to execute the function, leading to
strange errors or even crashes, depending on function contents and
server version.
To fix, add an isEventTrigger field to PLpgSQL_func_hashkey,
paralleling the longstanding infrastructure for regular triggers.
This fits into what had been pad space, so there's no risk of an ABI
break, even assuming that any third-party code is looking at these
hash keys. (I considered replacing isTrigger with a PLpgSQL_trigtype
enum field, but felt that that carried some API/ABI risk. Maybe we
should change it in HEAD though.)
Per bug #16266 from Alexander Lakhin. This has been broken since
event triggers were invented, so back-patch to all supported branches.
Discussion: https://postgr.es/m/16266-
fcd7f838e97ba5d4@postgresql.org
/* get call context */
hashkey->isTrigger = CALLED_AS_TRIGGER(fcinfo);
+ hashkey->isEventTrigger = CALLED_AS_EVENT_TRIGGER(fcinfo);
/*
- * if trigger, get its OID. In validation mode we do not know what
- * relation or transition table names are intended to be used, so we leave
- * trigOid zero; the hash entry built in this case will never really be
- * used.
+ * If DML trigger, include trigger's OID in the hash, so that each trigger
+ * usage gets a different hash entry, allowing for e.g. different relation
+ * rowtypes or transition table names. In validation mode we do not know
+ * what relation or transition table names are intended to be used, so we
+ * leave trigOid zero; the hash entry built in this case will never be
+ * used for any actual calls.
+ *
+ * We don't currently need to distinguish different event trigger usages
+ * in the same way, since the special parameter variables don't vary in
+ * type in that case.
*/
if (hashkey->isTrigger && !forValidator)
{
{
Oid funcOid;
- bool isTrigger; /* true if called as a trigger */
+ bool isTrigger; /* true if called as a DML trigger */
+ bool isEventTrigger; /* true if called as an event trigger */
/* be careful that pad bytes in this struct get zeroed! */
* For a trigger function, the OID of the trigger is part of the hash key
* --- we want to compile the trigger function separately for each trigger
* it is used with, in case the rowtype or transition table names are
- * different. Zero if not called as a trigger.
+ * different. Zero if not called as a DML trigger.
*/
Oid trigOid;
RAISE NOTICE 'test_event_trigger: % %', tg_event, tg_tag;
END
$$ language plpgsql;
+-- should fail, can't call it as a plain function
+SELECT test_event_trigger();
+ERROR: trigger functions can only be called as triggers
+CONTEXT: compilation of PL/pgSQL function "test_event_trigger" near line 1
-- should fail, event triggers cannot have declared arguments
create function test_event_trigger_arg(name text)
returns event_trigger as $$ BEGIN RETURN 1; END $$ language plpgsql;
END
$$ language plpgsql;
+-- should fail, can't call it as a plain function
+SELECT test_event_trigger();
+
-- should fail, event triggers cannot have declared arguments
create function test_event_trigger_arg(name text)
returns event_trigger as $$ BEGIN RETURN 1; END $$ language plpgsql;