pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Compare collations before merging UNION operations. 6+ messages / 1 participants [nested] [flat]
* pgsql: Compare collations before merging UNION operations. @ 2024-11-19 23:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-19 23:26 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compare collations before merging UNION operations. In the dim past we figured it was okay to ignore collations when combining UNION set-operation nodes into a single N-way UNION operation. I believe that was fine at the time, but it stopped being fine when we added nondeterministic collations: the semantics of distinct-ness are affected by those. v17 made it even less fine by allowing per-child sorting operations to be merged via MergeAppend, although I think we accidentally avoided any live bug from that. Add a check that collations match before deciding that two UNION nodes are equivalent. I also failed to resist the temptation to comment plan_union_children() a little better. Back-patch to all supported branches (v13 now), since they all have nondeterministic collations. Discussion: https://postgr.es/m/3605568.1731970579@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a43d7a8c7cce00e3fcf330e201a3a94f97097e64 Modified Files -------------- src/backend/optimizer/prep/prepunion.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Compare collations before merging UNION operations. @ 2024-11-19 23:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-19 23:26 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compare collations before merging UNION operations. In the dim past we figured it was okay to ignore collations when combining UNION set-operation nodes into a single N-way UNION operation. I believe that was fine at the time, but it stopped being fine when we added nondeterministic collations: the semantics of distinct-ness are affected by those. v17 made it even less fine by allowing per-child sorting operations to be merged via MergeAppend, although I think we accidentally avoided any live bug from that. Add a check that collations match before deciding that two UNION nodes are equivalent. I also failed to resist the temptation to comment plan_union_children() a little better. Back-patch to all supported branches (v13 now), since they all have nondeterministic collations. Discussion: https://postgr.es/m/3605568.1731970579@sss.pgh.pa.us Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c1ebef3c10dbfd8c6ec4c9b9ab03b7d1fe00ac79 Modified Files -------------- src/backend/optimizer/prep/prepunion.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Compare collations before merging UNION operations. @ 2024-11-19 23:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-19 23:26 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compare collations before merging UNION operations. In the dim past we figured it was okay to ignore collations when combining UNION set-operation nodes into a single N-way UNION operation. I believe that was fine at the time, but it stopped being fine when we added nondeterministic collations: the semantics of distinct-ness are affected by those. v17 made it even less fine by allowing per-child sorting operations to be merged via MergeAppend, although I think we accidentally avoided any live bug from that. Add a check that collations match before deciding that two UNION nodes are equivalent. I also failed to resist the temptation to comment plan_union_children() a little better. Back-patch to all supported branches (v13 now), since they all have nondeterministic collations. Discussion: https://postgr.es/m/3605568.1731970579@sss.pgh.pa.us Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f286f64bcf01106fc08ea1c14252ae2c26b7d189 Modified Files -------------- src/backend/optimizer/prep/prepunion.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Compare collations before merging UNION operations. @ 2024-11-19 23:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-19 23:26 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compare collations before merging UNION operations. In the dim past we figured it was okay to ignore collations when combining UNION set-operation nodes into a single N-way UNION operation. I believe that was fine at the time, but it stopped being fine when we added nondeterministic collations: the semantics of distinct-ness are affected by those. v17 made it even less fine by allowing per-child sorting operations to be merged via MergeAppend, although I think we accidentally avoided any live bug from that. Add a check that collations match before deciding that two UNION nodes are equivalent. I also failed to resist the temptation to comment plan_union_children() a little better. Back-patch to all supported branches (v13 now), since they all have nondeterministic collations. Discussion: https://postgr.es/m/3605568.1731970579@sss.pgh.pa.us Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/fd3383ff1107dd2d530178dd980423d96b3ade27 Modified Files -------------- src/backend/optimizer/prep/prepunion.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Compare collations before merging UNION operations. @ 2024-11-19 23:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-19 23:26 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compare collations before merging UNION operations. In the dim past we figured it was okay to ignore collations when combining UNION set-operation nodes into a single N-way UNION operation. I believe that was fine at the time, but it stopped being fine when we added nondeterministic collations: the semantics of distinct-ness are affected by those. v17 made it even less fine by allowing per-child sorting operations to be merged via MergeAppend, although I think we accidentally avoided any live bug from that. Add a check that collations match before deciding that two UNION nodes are equivalent. I also failed to resist the temptation to comment plan_union_children() a little better. Back-patch to all supported branches (v13 now), since they all have nondeterministic collations. Discussion: https://postgr.es/m/3605568.1731970579@sss.pgh.pa.us Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/44a4a521d03a0033fca696b5fa4725a436018ae6 Modified Files -------------- src/backend/optimizer/prep/prepunion.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Compare collations before merging UNION operations. @ 2024-11-19 23:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-11-19 23:26 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compare collations before merging UNION operations. In the dim past we figured it was okay to ignore collations when combining UNION set-operation nodes into a single N-way UNION operation. I believe that was fine at the time, but it stopped being fine when we added nondeterministic collations: the semantics of distinct-ness are affected by those. v17 made it even less fine by allowing per-child sorting operations to be merged via MergeAppend, although I think we accidentally avoided any live bug from that. Add a check that collations match before deciding that two UNION nodes are equivalent. I also failed to resist the temptation to comment plan_union_children() a little better. Back-patch to all supported branches (v13 now), since they all have nondeterministic collations. Discussion: https://postgr.es/m/3605568.1731970579@sss.pgh.pa.us Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6b66dba3f8d8b5f9fc761749e5f0643829f09307 Modified Files -------------- src/backend/optimizer/prep/prepunion.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-11-19 23:26 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-11-19 23:26 pgsql: Compare collations before merging UNION operations. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-19 23:26 pgsql: Compare collations before merging UNION operations. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-19 23:26 pgsql: Compare collations before merging UNION operations. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-19 23:26 pgsql: Compare collations before merging UNION operations. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-19 23:26 pgsql: Compare collations before merging UNION operations. Tom Lane <tgl@sss.pgh.pa.us> 2024-11-19 23:26 pgsql: Compare collations before merging UNION operations. 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