diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-02-19 14:44:58 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-02-19 14:44:58 -0500 |
commit | bbefb11541890d9add4b3b1ab2c53b26f4fc386b (patch) | |
tree | 3ec8c2cfc947118984aae612b556710c2ec313ee /src/backend/access/gist/gistget.c | |
parent | 4a3f164b74f56e91c3528e74166a1d45d6176f4d (diff) | |
download | postgresql-bbefb11541890d9add4b3b1ab2c53b26f4fc386b.tar.gz postgresql-bbefb11541890d9add4b3b1ab2c53b26f4fc386b.zip |
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
Diffstat (limited to 'src/backend/access/gist/gistget.c')
0 files changed, 0 insertions, 0 deletions