pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). @ 2024-06-04 22:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-04 22:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/b631d014987b9411ed0eeb7dcba9e0a8599bc3cf Modified Files -------------- src/pl/tcl/expected/pltcl_call.out | 8 ++++++++ src/pl/tcl/pltcl.c | 11 +++++++++-- src/pl/tcl/sql/pltcl_call.sql | 11 +++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). @ 2024-06-04 22:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-04 22:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1488dee08c4aa5b92a4cde66eb69b3e78e80a6d8 Modified Files -------------- src/pl/tcl/expected/pltcl_call.out | 8 ++++++++ src/pl/tcl/pltcl.c | 11 +++++++++-- src/pl/tcl/sql/pltcl_call.sql | 11 +++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). @ 2024-06-04 22:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-04 22:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/89ef2aedae448cc51cd7bf7c81d56a08d1da7467 Modified Files -------------- src/pl/tcl/expected/pltcl_call.out | 8 ++++++++ src/pl/tcl/pltcl.c | 11 +++++++++-- src/pl/tcl/sql/pltcl_call.sql | 11 +++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). @ 2024-06-04 22:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-04 22:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c236ecc82983ac01f504f7d6d286612fb9c3fad5 Modified Files -------------- src/pl/tcl/expected/pltcl_call.out | 8 ++++++++ src/pl/tcl/pltcl.c | 11 +++++++++-- src/pl/tcl/sql/pltcl_call.sql | 11 +++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). @ 2024-06-04 22:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-04 22:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dda633a039ee5f147e6315a786d7a162e898dc72 Modified Files -------------- src/pl/tcl/expected/pltcl_call.out | 8 ++++++++ src/pl/tcl/pltcl.c | 11 +++++++++-- src/pl/tcl/sql/pltcl_call.sql | 11 +++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). @ 2024-06-04 22:02 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-04 22:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/30487423c8296ea448f4deb56f5caec46111b763 Modified Files -------------- src/pl/tcl/expected/pltcl_call.out | 8 ++++++++ src/pl/tcl/pltcl.c | 11 +++++++++-- src/pl/tcl/sql/pltcl_call.sql | 11 +++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-06-04 22:02 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-04 22:02 pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). Tom Lane <tgl@sss.pgh.pa.us> 2024-06-04 22:02 pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). Tom Lane <tgl@sss.pgh.pa.us> 2024-06-04 22:02 pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). Tom Lane <tgl@sss.pgh.pa.us> 2024-06-04 22:02 pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). Tom Lane <tgl@sss.pgh.pa.us> 2024-06-04 22:02 pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). Tom Lane <tgl@sss.pgh.pa.us> 2024-06-04 22:02 pgsql: Fix pl/tcl's handling of errors from Tcl_ListObjGetElements(). Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox