pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. @ 2024-06-11 21:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-11 21:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is usually the first rangetable entry, so that that was fine. However, in cases such as inserting through an updatable view, it's not fine, leading to failure to match the expressions to the query with ensuing "there is no unique or exclusion constraint matching the ON CONFLICT specification" errors. Fix by copy-and-paste from get_relation_info(). Per bug #18502 from Michael Wang. Back-patch to all supported versions. Discussion: https://postgr.es/m/18502-545b53f5b81e54e0@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/915de706d28c433283e9dc63701e8f978488a2b9 Modified Files -------------- src/backend/optimizer/util/plancat.c | 9 ++++++++- src/test/regress/expected/insert_conflict.out | 13 +++++++++++++ src/test/regress/sql/insert_conflict.sql | 6 ++++++ 3 files changed, 27 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. @ 2024-06-11 21:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-11 21:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is usually the first rangetable entry, so that that was fine. However, in cases such as inserting through an updatable view, it's not fine, leading to failure to match the expressions to the query with ensuing "there is no unique or exclusion constraint matching the ON CONFLICT specification" errors. Fix by copy-and-paste from get_relation_info(). Per bug #18502 from Michael Wang. Back-patch to all supported versions. Discussion: https://postgr.es/m/18502-545b53f5b81e54e0@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b188e1bf75760fed76406a48c81bcd8ac6a8fda9 Modified Files -------------- src/backend/optimizer/util/plancat.c | 9 ++++++++- src/test/regress/expected/insert_conflict.out | 13 +++++++++++++ src/test/regress/sql/insert_conflict.sql | 6 ++++++ 3 files changed, 27 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. @ 2024-06-11 21:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-11 21:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is usually the first rangetable entry, so that that was fine. However, in cases such as inserting through an updatable view, it's not fine, leading to failure to match the expressions to the query with ensuing "there is no unique or exclusion constraint matching the ON CONFLICT specification" errors. Fix by copy-and-paste from get_relation_info(). Per bug #18502 from Michael Wang. Back-patch to all supported versions. Discussion: https://postgr.es/m/18502-545b53f5b81e54e0@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1d0399b54068586db003691c218c3d68bee055c8 Modified Files -------------- src/backend/optimizer/util/plancat.c | 9 ++++++++- src/test/regress/expected/insert_conflict.out | 13 +++++++++++++ src/test/regress/sql/insert_conflict.sql | 6 ++++++ 3 files changed, 27 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. @ 2024-06-11 21:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-11 21:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is usually the first rangetable entry, so that that was fine. However, in cases such as inserting through an updatable view, it's not fine, leading to failure to match the expressions to the query with ensuing "there is no unique or exclusion constraint matching the ON CONFLICT specification" errors. Fix by copy-and-paste from get_relation_info(). Per bug #18502 from Michael Wang. Back-patch to all supported versions. Discussion: https://postgr.es/m/18502-545b53f5b81e54e0@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/096f2132c66c9e267999707b3d83482749748520 Modified Files -------------- src/backend/optimizer/util/plancat.c | 9 ++++++++- src/test/regress/expected/insert_conflict.out | 13 +++++++++++++ src/test/regress/sql/insert_conflict.sql | 6 ++++++ 3 files changed, 27 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. @ 2024-06-11 21:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-11 21:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is usually the first rangetable entry, so that that was fine. However, in cases such as inserting through an updatable view, it's not fine, leading to failure to match the expressions to the query with ensuing "there is no unique or exclusion constraint matching the ON CONFLICT specification" errors. Fix by copy-and-paste from get_relation_info(). Per bug #18502 from Michael Wang. Back-patch to all supported versions. Discussion: https://postgr.es/m/18502-545b53f5b81e54e0@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5e8aa32a9ce78abcfea3ed157d7b66fb3bff5f58 Modified Files -------------- src/backend/optimizer/util/plancat.c | 9 ++++++++- src/test/regress/expected/insert_conflict.out | 13 +++++++++++++ src/test/regress/sql/insert_conflict.sql | 6 ++++++ 3 files changed, 27 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. @ 2024-06-11 21:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-11 21:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix infer_arbiter_indexes() to not assume resultRelation is 1. infer_arbiter_indexes failed to renumber varnos in index expressions or predicates that it got from the catalogs. This escaped detection up to now because the stored varnos in such trees will be 1, and an INSERT's result relation is usually the first rangetable entry, so that that was fine. However, in cases such as inserting through an updatable view, it's not fine, leading to failure to match the expressions to the query with ensuing "there is no unique or exclusion constraint matching the ON CONFLICT specification" errors. Fix by copy-and-paste from get_relation_info(). Per bug #18502 from Michael Wang. Back-patch to all supported versions. Discussion: https://postgr.es/m/18502-545b53f5b81e54e0@postgresql.org Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9256bf6eb35a06d5d78db1c3cae7e23225038172 Modified Files -------------- src/backend/optimizer/util/plancat.c | 9 ++++++++- src/test/regress/expected/insert_conflict.out | 13 +++++++++++++ src/test/regress/sql/insert_conflict.sql | 6 ++++++ 3 files changed, 27 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-06-11 21:58 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-11 21:58 pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. Tom Lane <tgl@sss.pgh.pa.us> 2024-06-11 21:58 pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. Tom Lane <tgl@sss.pgh.pa.us> 2024-06-11 21:58 pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. Tom Lane <tgl@sss.pgh.pa.us> 2024-06-11 21:58 pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. Tom Lane <tgl@sss.pgh.pa.us> 2024-06-11 21:58 pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. Tom Lane <tgl@sss.pgh.pa.us> 2024-06-11 21:58 pgsql: Fix infer_arbiter_indexes() to not assume resultRelation is 1. 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