pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix confusion about the return rowtype of SQL-language procedure 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix confusion about the return rowtype of SQL-language procedure @ 2024-03-12 22:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-03-12 22:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=Y8t0FJP-_SVSsRsnrQT76Gg@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6ee3261e9bb6f0aa30ec74896c57f69b0636bfdd Modified Files -------------- src/backend/catalog/pg_proc.c | 1 + src/backend/executor/functions.c | 11 +++++++++-- src/backend/optimizer/util/clauses.c | 2 ++ src/include/executor/functions.h | 1 + src/test/regress/expected/create_procedure.out | 14 +++++++++++++- src/test/regress/sql/create_procedure.sql | 11 ++++++++++- 6 files changed, 36 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix confusion about the return rowtype of SQL-language procedure @ 2024-03-12 22:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-03-12 22:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=Y8t0FJP-_SVSsRsnrQT76Gg@mail.gmail.com Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dc1503d5b8b3a1565702dd13e8874f74211a8e09 Modified Files -------------- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 34 ++++++++++++++++++++------ src/backend/optimizer/util/clauses.c | 12 +++++---- src/include/executor/functions.h | 6 +++++ src/test/regress/expected/create_procedure.out | 14 ++++++++++- src/test/regress/sql/create_procedure.sql | 11 ++++++++- 6 files changed, 67 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix confusion about the return rowtype of SQL-language procedure @ 2024-03-12 22:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-03-12 22:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=Y8t0FJP-_SVSsRsnrQT76Gg@mail.gmail.com Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/28184f039e3364a4a8e341dcbd713372689728db Modified Files -------------- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 35 ++++++++++++++++++++------ src/backend/optimizer/util/clauses.c | 14 ++++++----- src/include/executor/functions.h | 6 +++++ src/test/regress/expected/create_procedure.out | 14 ++++++++++- src/test/regress/sql/create_procedure.sql | 11 +++++++- 6 files changed, 69 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix confusion about the return rowtype of SQL-language procedure @ 2024-03-12 22:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-03-12 22:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=Y8t0FJP-_SVSsRsnrQT76Gg@mail.gmail.com Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/649bbba1134dce05998e26137fcb32d0e0cb6311 Modified Files -------------- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 35 ++++++++++++++++++++------ src/backend/optimizer/util/clauses.c | 14 ++++++----- src/include/executor/functions.h | 6 +++++ src/test/regress/expected/create_procedure.out | 14 ++++++++++- src/test/regress/sql/create_procedure.sql | 11 +++++++- 6 files changed, 69 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix confusion about the return rowtype of SQL-language procedure @ 2024-03-12 22:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-03-12 22:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=Y8t0FJP-_SVSsRsnrQT76Gg@mail.gmail.com Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6f66fadad91b61f2f3415aafe14f52c2e5e6ad88 Modified Files -------------- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 35 ++++++++++++++++++++------ src/backend/optimizer/util/clauses.c | 14 ++++++----- src/include/executor/functions.h | 6 +++++ src/test/regress/expected/create_procedure.out | 14 ++++++++++- src/test/regress/sql/create_procedure.sql | 11 +++++++- 6 files changed, 69 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix confusion about the return rowtype of SQL-language procedure @ 2024-03-12 22:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-03-12 22:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=Y8t0FJP-_SVSsRsnrQT76Gg@mail.gmail.com Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/40d1bdeb72b2d7dfa9e0d91785f0a056b719ebb1 Modified Files -------------- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 35 ++++++++++++++++++++------ src/backend/optimizer/util/clauses.c | 14 ++++++----- src/include/executor/functions.h | 6 +++++ src/test/regress/expected/create_procedure.out | 14 ++++++++++- src/test/regress/sql/create_procedure.sql | 11 +++++++- 6 files changed, 69 insertions(+), 18 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-03-12 22:16 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-03-12 22:16 pgsql: Fix confusion about the return rowtype of SQL-language procedure Tom Lane <tgl@sss.pgh.pa.us> 2024-03-12 22:16 pgsql: Fix confusion about the return rowtype of SQL-language procedure Tom Lane <tgl@sss.pgh.pa.us> 2024-03-12 22:16 pgsql: Fix confusion about the return rowtype of SQL-language procedure Tom Lane <tgl@sss.pgh.pa.us> 2024-03-12 22:16 pgsql: Fix confusion about the return rowtype of SQL-language procedure Tom Lane <tgl@sss.pgh.pa.us> 2024-03-12 22:16 pgsql: Fix confusion about the return rowtype of SQL-language procedure Tom Lane <tgl@sss.pgh.pa.us> 2024-03-12 22:16 pgsql: Fix confusion about the return rowtype of SQL-language procedure 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