public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input @ 2025-03-13 20:08 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-13 20:08 UTC (permalink / raw) To: [email protected] Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input. If the given input_type yields valid results from both get_element_type and get_array_type, initArrayResultAny believed the former and treated the input as an array type. However this is inconsistent with what get_promoted_array_type does, leading to situations where the output of an ARRAY() subquery is labeled with the wrong type: it's labeled as oidvector[] but is really a 2-D array of OID. That at least results in strange output, and can result in crashes if further processing such as unnest() is applied. AFAIK this is only possible with the int2vector and oidvector types, which are special-cased to be treated mostly as true arrays even though they aren't quite. Fix by switching the logic to match get_promoted_array_type by testing get_array_type not get_element_type, and remove an Assert thereby made pointless. (We need not introduce a symmetrical check for get_element_type in the other if-branch, because initArrayResultArr will check it.) This restores the behavior that existed before bac27394a introduced initArrayResultAny: the output really is int2vector[] or oidvector[]. Comparable confusion exists when an input of an ARRAY[] construct is int2vector or oidvector: transformArrayExpr decides it's dealing with a multidimensional array constructor, and we end up with something that's a multidimensional OID array but is alleged to be of type oidvector. I have not found a crashing case here, but it's easy to demonstrate totally-wrong results. Adjust that code so that what you get is an oidvector[] instead, for consistency with ARRAY() subqueries. (This change also makes these types work like domains-over-arrays in this context, which seems correct.) Bug: #18840 Reported-by: yang lei <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f7ae51312f3d5366ab958c43239ca142aeb11a70 Modified Files -------------- src/backend/parser/parse_expr.c | 14 +++- src/backend/utils/adt/arrayfuncs.c | 12 ++-- src/test/regress/expected/arrays.out | 126 +++++++++++++++++++++++++++++++++++ src/test/regress/sql/arrays.sql | 22 ++++++ 4 files changed, 166 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input @ 2025-03-13 20:08 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-13 20:08 UTC (permalink / raw) To: [email protected] Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input. If the given input_type yields valid results from both get_element_type and get_array_type, initArrayResultAny believed the former and treated the input as an array type. However this is inconsistent with what get_promoted_array_type does, leading to situations where the output of an ARRAY() subquery is labeled with the wrong type: it's labeled as oidvector[] but is really a 2-D array of OID. That at least results in strange output, and can result in crashes if further processing such as unnest() is applied. AFAIK this is only possible with the int2vector and oidvector types, which are special-cased to be treated mostly as true arrays even though they aren't quite. Fix by switching the logic to match get_promoted_array_type by testing get_array_type not get_element_type, and remove an Assert thereby made pointless. (We need not introduce a symmetrical check for get_element_type in the other if-branch, because initArrayResultArr will check it.) This restores the behavior that existed before bac27394a introduced initArrayResultAny: the output really is int2vector[] or oidvector[]. Comparable confusion exists when an input of an ARRAY[] construct is int2vector or oidvector: transformArrayExpr decides it's dealing with a multidimensional array constructor, and we end up with something that's a multidimensional OID array but is alleged to be of type oidvector. I have not found a crashing case here, but it's easy to demonstrate totally-wrong results. Adjust that code so that what you get is an oidvector[] instead, for consistency with ARRAY() subqueries. (This change also makes these types work like domains-over-arrays in this context, which seems correct.) Bug: #18840 Reported-by: yang lei <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0405982c7cbab6e16245df848e9d110bd0284fa0 Modified Files -------------- src/backend/parser/parse_expr.c | 14 +++- src/backend/utils/adt/arrayfuncs.c | 12 ++-- src/test/regress/expected/arrays.out | 126 +++++++++++++++++++++++++++++++++++ src/test/regress/sql/arrays.sql | 22 ++++++ 4 files changed, 166 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input @ 2025-03-13 20:08 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-13 20:08 UTC (permalink / raw) To: [email protected] Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input. If the given input_type yields valid results from both get_element_type and get_array_type, initArrayResultAny believed the former and treated the input as an array type. However this is inconsistent with what get_promoted_array_type does, leading to situations where the output of an ARRAY() subquery is labeled with the wrong type: it's labeled as oidvector[] but is really a 2-D array of OID. That at least results in strange output, and can result in crashes if further processing such as unnest() is applied. AFAIK this is only possible with the int2vector and oidvector types, which are special-cased to be treated mostly as true arrays even though they aren't quite. Fix by switching the logic to match get_promoted_array_type by testing get_array_type not get_element_type, and remove an Assert thereby made pointless. (We need not introduce a symmetrical check for get_element_type in the other if-branch, because initArrayResultArr will check it.) This restores the behavior that existed before bac27394a introduced initArrayResultAny: the output really is int2vector[] or oidvector[]. Comparable confusion exists when an input of an ARRAY[] construct is int2vector or oidvector: transformArrayExpr decides it's dealing with a multidimensional array constructor, and we end up with something that's a multidimensional OID array but is alleged to be of type oidvector. I have not found a crashing case here, but it's easy to demonstrate totally-wrong results. Adjust that code so that what you get is an oidvector[] instead, for consistency with ARRAY() subqueries. (This change also makes these types work like domains-over-arrays in this context, which seems correct.) Bug: #18840 Reported-by: yang lei <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/13dd6f77265b9738d29eb33f2dcd6d9361e92700 Modified Files -------------- src/backend/parser/parse_expr.c | 14 +++- src/backend/utils/adt/arrayfuncs.c | 12 ++-- src/test/regress/expected/arrays.out | 126 +++++++++++++++++++++++++++++++++++ src/test/regress/sql/arrays.sql | 22 ++++++ 4 files changed, 166 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input @ 2025-03-13 20:08 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-13 20:08 UTC (permalink / raw) To: [email protected] Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input. If the given input_type yields valid results from both get_element_type and get_array_type, initArrayResultAny believed the former and treated the input as an array type. However this is inconsistent with what get_promoted_array_type does, leading to situations where the output of an ARRAY() subquery is labeled with the wrong type: it's labeled as oidvector[] but is really a 2-D array of OID. That at least results in strange output, and can result in crashes if further processing such as unnest() is applied. AFAIK this is only possible with the int2vector and oidvector types, which are special-cased to be treated mostly as true arrays even though they aren't quite. Fix by switching the logic to match get_promoted_array_type by testing get_array_type not get_element_type, and remove an Assert thereby made pointless. (We need not introduce a symmetrical check for get_element_type in the other if-branch, because initArrayResultArr will check it.) This restores the behavior that existed before bac27394a introduced initArrayResultAny: the output really is int2vector[] or oidvector[]. Comparable confusion exists when an input of an ARRAY[] construct is int2vector or oidvector: transformArrayExpr decides it's dealing with a multidimensional array constructor, and we end up with something that's a multidimensional OID array but is alleged to be of type oidvector. I have not found a crashing case here, but it's easy to demonstrate totally-wrong results. Adjust that code so that what you get is an oidvector[] instead, for consistency with ARRAY() subqueries. (This change also makes these types work like domains-over-arrays in this context, which seems correct.) Bug: #18840 Reported-by: yang lei <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/474aee3dfe8860994893959ef1566c51d3304aa3 Modified Files -------------- src/backend/parser/parse_expr.c | 14 +++- src/backend/utils/adt/arrayfuncs.c | 12 ++-- src/test/regress/expected/arrays.out | 126 +++++++++++++++++++++++++++++++++++ src/test/regress/sql/arrays.sql | 22 ++++++ 4 files changed, 166 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input @ 2025-03-13 20:08 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-13 20:08 UTC (permalink / raw) To: [email protected] Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input. If the given input_type yields valid results from both get_element_type and get_array_type, initArrayResultAny believed the former and treated the input as an array type. However this is inconsistent with what get_promoted_array_type does, leading to situations where the output of an ARRAY() subquery is labeled with the wrong type: it's labeled as oidvector[] but is really a 2-D array of OID. That at least results in strange output, and can result in crashes if further processing such as unnest() is applied. AFAIK this is only possible with the int2vector and oidvector types, which are special-cased to be treated mostly as true arrays even though they aren't quite. Fix by switching the logic to match get_promoted_array_type by testing get_array_type not get_element_type, and remove an Assert thereby made pointless. (We need not introduce a symmetrical check for get_element_type in the other if-branch, because initArrayResultArr will check it.) This restores the behavior that existed before bac27394a introduced initArrayResultAny: the output really is int2vector[] or oidvector[]. Comparable confusion exists when an input of an ARRAY[] construct is int2vector or oidvector: transformArrayExpr decides it's dealing with a multidimensional array constructor, and we end up with something that's a multidimensional OID array but is alleged to be of type oidvector. I have not found a crashing case here, but it's easy to demonstrate totally-wrong results. Adjust that code so that what you get is an oidvector[] instead, for consistency with ARRAY() subqueries. (This change also makes these types work like domains-over-arrays in this context, which seems correct.) Bug: #18840 Reported-by: yang lei <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/4618045bee4a6d3efcb489c319649d8dd9aaa738 Modified Files -------------- src/backend/parser/parse_expr.c | 14 +++- src/backend/utils/adt/arrayfuncs.c | 12 ++-- src/test/regress/expected/arrays.out | 126 +++++++++++++++++++++++++++++++++++ src/test/regress/sql/arrays.sql | 22 ++++++ 4 files changed, 166 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input @ 2025-03-13 20:08 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-13 20:08 UTC (permalink / raw) To: [email protected] Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input. If the given input_type yields valid results from both get_element_type and get_array_type, initArrayResultAny believed the former and treated the input as an array type. However this is inconsistent with what get_promoted_array_type does, leading to situations where the output of an ARRAY() subquery is labeled with the wrong type: it's labeled as oidvector[] but is really a 2-D array of OID. That at least results in strange output, and can result in crashes if further processing such as unnest() is applied. AFAIK this is only possible with the int2vector and oidvector types, which are special-cased to be treated mostly as true arrays even though they aren't quite. Fix by switching the logic to match get_promoted_array_type by testing get_array_type not get_element_type, and remove an Assert thereby made pointless. (We need not introduce a symmetrical check for get_element_type in the other if-branch, because initArrayResultArr will check it.) This restores the behavior that existed before bac27394a introduced initArrayResultAny: the output really is int2vector[] or oidvector[]. Comparable confusion exists when an input of an ARRAY[] construct is int2vector or oidvector: transformArrayExpr decides it's dealing with a multidimensional array constructor, and we end up with something that's a multidimensional OID array but is alleged to be of type oidvector. I have not found a crashing case here, but it's easy to demonstrate totally-wrong results. Adjust that code so that what you get is an oidvector[] instead, for consistency with ARRAY() subqueries. (This change also makes these types work like domains-over-arrays in this context, which seems correct.) Bug: #18840 Reported-by: yang lei <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c826cd1b1d42823406360ab5f795490ca8744961 Modified Files -------------- src/backend/parser/parse_expr.c | 14 +++- src/backend/utils/adt/arrayfuncs.c | 12 ++-- src/test/regress/expected/arrays.out | 126 +++++++++++++++++++++++++++++++++++ src/test/regress/sql/arrays.sql | 22 ++++++ 4 files changed, 166 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-03-13 20:08 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-03-13 20:08 pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input Tom Lane <[email protected]> 2025-03-13 20:08 pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input Tom Lane <[email protected]> 2025-03-13 20:08 pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input Tom Lane <[email protected]> 2025-03-13 20:08 pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input Tom Lane <[email protected]> 2025-03-13 20:08 pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input Tom Lane <[email protected]> 2025-03-13 20:08 pgsql: Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input 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