pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix recursive RECORD-returning plpython functions. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix recursive RECORD-returning plpython functions. @ 2024-05-09 17:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-09 17:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2728677923d2a025575dee4a24580e3e899c5615 Modified Files -------------- src/pl/plpython/expected/plpython_composite.out | 14 +++++++++++ src/pl/plpython/plpy_exec.c | 33 +++++++++++++------------ src/pl/plpython/sql/plpython_composite.sql | 11 +++++++++ 3 files changed, 42 insertions(+), 16 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix recursive RECORD-returning plpython functions. @ 2024-05-09 17:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-09 17:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d39337021e12d569e3241a605120f010f77b9e22 Modified Files -------------- src/pl/plpython/expected/plpython_composite.out | 14 +++++++++++ src/pl/plpython/plpy_exec.c | 33 +++++++++++++------------ src/pl/plpython/sql/plpython_composite.sql | 11 +++++++++ 3 files changed, 42 insertions(+), 16 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix recursive RECORD-returning plpython functions. @ 2024-05-09 17:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-09 17:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6e29963edd55cfc038304322049d8fe697580f2c Modified Files -------------- src/pl/plpython/expected/plpython_composite.out | 14 +++++++++++ src/pl/plpython/plpy_exec.c | 33 +++++++++++++------------ src/pl/plpython/sql/plpython_composite.sql | 11 +++++++++ 3 files changed, 42 insertions(+), 16 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix recursive RECORD-returning plpython functions. @ 2024-05-09 17:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-09 17:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/157b1e6b41b4a1f4bdb3166c791bb3a103abd8c4 Modified Files -------------- src/pl/plpython/expected/plpython_composite.out | 14 +++++++++++ src/pl/plpython/plpy_exec.c | 33 +++++++++++++------------ src/pl/plpython/sql/plpython_composite.sql | 11 +++++++++ 3 files changed, 42 insertions(+), 16 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix recursive RECORD-returning plpython functions. @ 2024-05-09 17:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-09 17:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d727c543176c32205372991d3e036e5349fb719d Modified Files -------------- src/pl/plpython/expected/plpython_composite.out | 14 +++++++++++ src/pl/plpython/plpy_exec.c | 33 +++++++++++++------------ src/pl/plpython/sql/plpython_composite.sql | 11 +++++++++ 3 files changed, 42 insertions(+), 16 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix recursive RECORD-returning plpython functions. @ 2024-05-09 17:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-09 17:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/52ea653aa9d867be70b2d86fe8310dde48507b6a Modified Files -------------- src/pl/plpython/expected/plpython_composite.out | 14 +++++++++++ src/pl/plpython/plpy_exec.c | 33 +++++++++++++------------ src/pl/plpython/sql/plpython_composite.sql | 11 +++++++++ 3 files changed, 42 insertions(+), 16 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-05-09 17:16 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-05-09 17:16 pgsql: Fix recursive RECORD-returning plpython functions. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-09 17:16 pgsql: Fix recursive RECORD-returning plpython functions. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-09 17:16 pgsql: Fix recursive RECORD-returning plpython functions. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-09 17:16 pgsql: Fix recursive RECORD-returning plpython functions. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-09 17:16 pgsql: Fix recursive RECORD-returning plpython functions. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-09 17:16 pgsql: Fix recursive RECORD-returning plpython functions. 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