aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/functions.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-06-04 18:02:13 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-06-04 18:02:13 -0400
commit30487423c8296ea448f4deb56f5caec46111b763 (patch)
tree74298bfc266aed02bb7856a2931541135f53c442 /src/backend/executor/functions.c
parent09d7caad32d8d6987964a85ff71d12f18f63f43f (diff)
downloadpostgresql-30487423c8296ea448f4deb56f5caec46111b763.tar.gz
postgresql-30487423c8296ea448f4deb56f5caec46111b763.zip
Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().
In a procedure or function returning tuple, we use that function to parse the Tcl script's result, which is supposed to be a Tcl list. If it isn't, you get an error. Commit 26abb50c4 incautiously supposed that we could use throw_tcl_error() to report such an error. That doesn't actually work, because low-level functions like Tcl_ListObjGetElements() don't fill Tcl's errorInfo variable. The result is either a null-pointer-dereference crash or emission of misleading context information describing the previous Tcl error. Back off to just reporting the interpreter's result string, and improve throw_tcl_error()'s comment to explain when to use it. Also, although the similar code in pltcl_trigger_handler() avoided this mistake, it was using a fairly confusing wording of the error message. Improve that while we're here. Per report from A. Kozhemyakin. Back-patch to all supported branches. Erik Wienhold and Tom Lane Discussion: https://postgr.es/m/6a2a1c40-2b2c-4a33-8b72-243c0766fcda@postgrespro.ru
Diffstat (limited to 'src/backend/executor/functions.c')
0 files changed, 0 insertions, 0 deletions