diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2024-06-04 18:02:13 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2024-06-04 18:02:13 -0400 |
commit | 1488dee08c4aa5b92a4cde66eb69b3e78e80a6d8 (patch) | |
tree | 37b7da310e60e3f91b4d89e545d0bceb3e08c315 /src/backend/executor/nodeModifyTable.c | |
parent | d0c11ea29846e66a49eecc62260d11709da3c73e (diff) | |
download | postgresql-1488dee08c4aa5b92a4cde66eb69b3e78e80a6d8.tar.gz postgresql-1488dee08c4aa5b92a4cde66eb69b3e78e80a6d8.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/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions