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:44:58 +0000 (14:44 -0500)
commit612d207bcc05d1048a8648407b064df14cd3104a
tree55f44fca025b980e8f9778700bb145bc85508334
parent414ed1ca232134e512ecfed1849f092f24f2a27a
Fix confusion about event trigger vs. plain function in plpgsql.

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