public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Fix plpgsql's handling of "return simple_record_variable". 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix plpgsql's handling of "return simple_record_variable". @ 2026-02-11 21:53 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-11 21:53 UTC (permalink / raw) To: [email protected] Fix plpgsql's handling of "return simple_record_variable". If the variable's value is null, exec_stmt_return() missed filling in estate->rettype. This is a pretty old bug, but we'd managed not to notice because that value isn't consulted for a null result ... unless we have to cast it to a domain. That case led to a failure with "cache lookup failed for type 0". The correct way to assign the data type is known by exec_eval_datum. While we could copy-and-paste that logic, it seems like a better idea to just invoke exec_eval_datum, as the ROW case already does. Reported-by: Pavel Stehule <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c66f4cff1a2e968ff86ffa6608ae8db12f7b1b31 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_domain.out | 13 +++++++++++++ src/pl/plpgsql/src/pl_exec.c | 20 +++----------------- src/pl/plpgsql/src/sql/plpgsql_domain.sql | 10 ++++++++++ 3 files changed, 26 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of "return simple_record_variable". @ 2026-02-11 21:53 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-11 21:53 UTC (permalink / raw) To: [email protected] Fix plpgsql's handling of "return simple_record_variable". If the variable's value is null, exec_stmt_return() missed filling in estate->rettype. This is a pretty old bug, but we'd managed not to notice because that value isn't consulted for a null result ... unless we have to cast it to a domain. That case led to a failure with "cache lookup failed for type 0". The correct way to assign the data type is known by exec_eval_datum. While we could copy-and-paste that logic, it seems like a better idea to just invoke exec_eval_datum, as the ROW case already does. Reported-by: Pavel Stehule <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/254b15cbf1e91ca33620027ca016e67668a321c1 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_domain.out | 13 +++++++++++++ src/pl/plpgsql/src/pl_exec.c | 20 +++----------------- src/pl/plpgsql/src/sql/plpgsql_domain.sql | 10 ++++++++++ 3 files changed, 26 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of "return simple_record_variable". @ 2026-02-11 21:53 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-11 21:53 UTC (permalink / raw) To: [email protected] Fix plpgsql's handling of "return simple_record_variable". If the variable's value is null, exec_stmt_return() missed filling in estate->rettype. This is a pretty old bug, but we'd managed not to notice because that value isn't consulted for a null result ... unless we have to cast it to a domain. That case led to a failure with "cache lookup failed for type 0". The correct way to assign the data type is known by exec_eval_datum. While we could copy-and-paste that logic, it seems like a better idea to just invoke exec_eval_datum, as the ROW case already does. Reported-by: Pavel Stehule <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2b93d382055b62e1493cfbb6c3b5547c1bb9ab82 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_domain.out | 13 +++++++++++++ src/pl/plpgsql/src/pl_exec.c | 20 +++----------------- src/pl/plpgsql/src/sql/plpgsql_domain.sql | 10 ++++++++++ 3 files changed, 26 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of "return simple_record_variable". @ 2026-02-11 21:53 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-11 21:53 UTC (permalink / raw) To: [email protected] Fix plpgsql's handling of "return simple_record_variable". If the variable's value is null, exec_stmt_return() missed filling in estate->rettype. This is a pretty old bug, but we'd managed not to notice because that value isn't consulted for a null result ... unless we have to cast it to a domain. That case led to a failure with "cache lookup failed for type 0". The correct way to assign the data type is known by exec_eval_datum. While we could copy-and-paste that logic, it seems like a better idea to just invoke exec_eval_datum, as the ROW case already does. Reported-by: Pavel Stehule <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ce4b7e3a1058eb3edd7511f2770379d7f78bd3a0 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_domain.out | 13 +++++++++++++ src/pl/plpgsql/src/pl_exec.c | 20 +++----------------- src/pl/plpgsql/src/sql/plpgsql_domain.sql | 10 ++++++++++ 3 files changed, 26 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of "return simple_record_variable". @ 2026-02-11 21:53 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-11 21:53 UTC (permalink / raw) To: [email protected] Fix plpgsql's handling of "return simple_record_variable". If the variable's value is null, exec_stmt_return() missed filling in estate->rettype. This is a pretty old bug, but we'd managed not to notice because that value isn't consulted for a null result ... unless we have to cast it to a domain. That case led to a failure with "cache lookup failed for type 0". The correct way to assign the data type is known by exec_eval_datum. While we could copy-and-paste that logic, it seems like a better idea to just invoke exec_eval_datum, as the ROW case already does. Reported-by: Pavel Stehule <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/9863c90759ecb3c200520db9a8b02c33eaec6e17 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_domain.out | 13 +++++++++++++ src/pl/plpgsql/src/pl_exec.c | 20 +++----------------- src/pl/plpgsql/src/sql/plpgsql_domain.sql | 10 ++++++++++ 3 files changed, 26 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of "return simple_record_variable". @ 2026-02-11 21:53 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-11 21:53 UTC (permalink / raw) To: [email protected] Fix plpgsql's handling of "return simple_record_variable". If the variable's value is null, exec_stmt_return() missed filling in estate->rettype. This is a pretty old bug, but we'd managed not to notice because that value isn't consulted for a null result ... unless we have to cast it to a domain. That case led to a failure with "cache lookup failed for type 0". The correct way to assign the data type is known by exec_eval_datum. While we could copy-and-paste that logic, it seems like a better idea to just invoke exec_eval_datum, as the ROW case already does. Reported-by: Pavel Stehule <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dfd85098030475dbc38abe623f852d3aa1e1a40b Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_domain.out | 13 +++++++++++++ src/pl/plpgsql/src/pl_exec.c | 20 +++----------------- src/pl/plpgsql/src/sql/plpgsql_domain.sql | 10 ++++++++++ 3 files changed, 26 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-02-11 21:53 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-02-11 21:53 pgsql: Fix plpgsql's handling of "return simple_record_variable". Tom Lane <[email protected]> 2026-02-11 21:53 pgsql: Fix plpgsql's handling of "return simple_record_variable". Tom Lane <[email protected]> 2026-02-11 21:53 pgsql: Fix plpgsql's handling of "return simple_record_variable". Tom Lane <[email protected]> 2026-02-11 21:53 pgsql: Fix plpgsql's handling of "return simple_record_variable". Tom Lane <[email protected]> 2026-02-11 21:53 pgsql: Fix plpgsql's handling of "return simple_record_variable". Tom Lane <[email protected]> 2026-02-11 21:53 pgsql: Fix plpgsql's handling of "return simple_record_variable". Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox