Fix confusion about event trigger vs. plain function in plpgsql.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 19 Feb 2020 19:44:58 +0000 (14:44 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 19 Feb 2020 19:45:17 +0000 (14:45 -0500)
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

src/pl/plpgsql/src/pl_comp.c
src/pl/plpgsql/src/plpgsql.h
src/test/regress/expected/event_trigger.out
src/test/regress/sql/event_trigger.sql

index 66bf9f12116c99b54525121865b72dffcca814ae..4f6b36b145a58b9eb0109947941a18c4b489721f 100644 (file)
@@ -2418,12 +2418,19 @@ compute_function_hashkey(FunctionCallInfo fcinfo,
 
    /* 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)
    {
index b599f67fc5812d28a07a07da1864423927ab2a48..69df3306fda0733a42d3783ca3267f919e883acb 100644 (file)
@@ -939,7 +939,8 @@ typedef struct PLpgSQL_func_hashkey
 {
    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! */
 
@@ -947,7 +948,7 @@ typedef struct PLpgSQL_func_hashkey
     * 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;
 
index 788be86b33a7c95cc6f5d2b97b95d04bdb50303f..bdd0ffcdaf3d7291db590e3358efded7a44d19e8 100644 (file)
@@ -9,6 +9,10 @@ BEGIN
     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;
index 346168673dbca9b6f90a7b7fcc4cf039f6835108..18b2a267cbe912d0ee52ba74a20c5b8d7cb2e055 100644 (file)
@@ -10,6 +10,9 @@ BEGIN
 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;