aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistbuild.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-02-19 14:44:58 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2020-02-19 14:44:58 -0500
commit612d207bcc05d1048a8648407b064df14cd3104a (patch)
tree55f44fca025b980e8f9778700bb145bc85508334 /src/backend/access/gist/gistbuild.c
parent414ed1ca232134e512ecfed1849f092f24f2a27a (diff)
downloadpostgresql-612d207bcc05d1048a8648407b064df14cd3104a.tar.gz
postgresql-612d207bcc05d1048a8648407b064df14cd3104a.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/gistbuild.c')
0 files changed, 0 insertions, 0 deletions