pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. @ 2025-09-27 18:29 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-09-27 18:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed copying of groupDistinct in transformPLAssignStmt. Because we failed to do this, DISTINCT in GROUP BY DISTINCT would be ignored in PL/pgSQL assignment statements. It's not surprising that no one noticed, since such statements will throw an error if the query produces more than one row. That eliminates most scenarios where advanced forms of GROUP BY could be useful, and indeed makes it hard even to find a simple test case. Nonetheless it's wrong. This is directly the fault of be45be9c3 which added the groupDistinct field, but I think much of the blame has to fall on c9d529848, in which I incautiously supposed that we'd manage to keep two copies of a big chunk of parse-analysis logic in sync. As a follow-up, I plan to refactor so that there's only one copy. But that seems useful only in master, so let's use this one-line fix for the back branches. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/31027.1758919078@sss.pgh.pa.us Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/7504d2be9eb45207b48476919e4539d93c389d86 Modified Files -------------- src/backend/parser/analyze.c | 1 + 1 file changed, 1 insertion(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. @ 2025-09-27 18:29 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-09-27 18:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed copying of groupDistinct in transformPLAssignStmt. Because we failed to do this, DISTINCT in GROUP BY DISTINCT would be ignored in PL/pgSQL assignment statements. It's not surprising that no one noticed, since such statements will throw an error if the query produces more than one row. That eliminates most scenarios where advanced forms of GROUP BY could be useful, and indeed makes it hard even to find a simple test case. Nonetheless it's wrong. This is directly the fault of be45be9c3 which added the groupDistinct field, but I think much of the blame has to fall on c9d529848, in which I incautiously supposed that we'd manage to keep two copies of a big chunk of parse-analysis logic in sync. As a follow-up, I plan to refactor so that there's only one copy. But that seems useful only in master, so let's use this one-line fix for the back branches. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/31027.1758919078@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/78a284b0b8d4add8457325b74144bd762156cb0e Modified Files -------------- src/backend/parser/analyze.c | 1 + 1 file changed, 1 insertion(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. @ 2025-09-27 18:29 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-09-27 18:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed copying of groupDistinct in transformPLAssignStmt. Because we failed to do this, DISTINCT in GROUP BY DISTINCT would be ignored in PL/pgSQL assignment statements. It's not surprising that no one noticed, since such statements will throw an error if the query produces more than one row. That eliminates most scenarios where advanced forms of GROUP BY could be useful, and indeed makes it hard even to find a simple test case. Nonetheless it's wrong. This is directly the fault of be45be9c3 which added the groupDistinct field, but I think much of the blame has to fall on c9d529848, in which I incautiously supposed that we'd manage to keep two copies of a big chunk of parse-analysis logic in sync. As a follow-up, I plan to refactor so that there's only one copy. But that seems useful only in master, so let's use this one-line fix for the back branches. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/31027.1758919078@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3fc9aa5b0233883e0f73902200777d251e848e18 Modified Files -------------- src/backend/parser/analyze.c | 1 + 1 file changed, 1 insertion(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. @ 2025-09-27 18:29 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-09-27 18:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed copying of groupDistinct in transformPLAssignStmt. Because we failed to do this, DISTINCT in GROUP BY DISTINCT would be ignored in PL/pgSQL assignment statements. It's not surprising that no one noticed, since such statements will throw an error if the query produces more than one row. That eliminates most scenarios where advanced forms of GROUP BY could be useful, and indeed makes it hard even to find a simple test case. Nonetheless it's wrong. This is directly the fault of be45be9c3 which added the groupDistinct field, but I think much of the blame has to fall on c9d529848, in which I incautiously supposed that we'd manage to keep two copies of a big chunk of parse-analysis logic in sync. As a follow-up, I plan to refactor so that there's only one copy. But that seems useful only in master, so let's use this one-line fix for the back branches. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/31027.1758919078@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b7f6798c056a0ca96c0f01750f382213b0ad3375 Modified Files -------------- src/backend/parser/analyze.c | 1 + 1 file changed, 1 insertion(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. @ 2025-09-27 18:29 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-09-27 18:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed copying of groupDistinct in transformPLAssignStmt. Because we failed to do this, DISTINCT in GROUP BY DISTINCT would be ignored in PL/pgSQL assignment statements. It's not surprising that no one noticed, since such statements will throw an error if the query produces more than one row. That eliminates most scenarios where advanced forms of GROUP BY could be useful, and indeed makes it hard even to find a simple test case. Nonetheless it's wrong. This is directly the fault of be45be9c3 which added the groupDistinct field, but I think much of the blame has to fall on c9d529848, in which I incautiously supposed that we'd manage to keep two copies of a big chunk of parse-analysis logic in sync. As a follow-up, I plan to refactor so that there's only one copy. But that seems useful only in master, so let's use this one-line fix for the back branches. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/31027.1758919078@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9ca79896aba3584dd7ed856ba148e0d8c5fe6cc2 Modified Files -------------- src/backend/parser/analyze.c | 1 + 1 file changed, 1 insertion(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. @ 2025-09-27 18:29 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-09-27 18:29 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix missed copying of groupDistinct in transformPLAssignStmt. Because we failed to do this, DISTINCT in GROUP BY DISTINCT would be ignored in PL/pgSQL assignment statements. It's not surprising that no one noticed, since such statements will throw an error if the query produces more than one row. That eliminates most scenarios where advanced forms of GROUP BY could be useful, and indeed makes it hard even to find a simple test case. Nonetheless it's wrong. This is directly the fault of be45be9c3 which added the groupDistinct field, but I think much of the blame has to fall on c9d529848, in which I incautiously supposed that we'd manage to keep two copies of a big chunk of parse-analysis logic in sync. As a follow-up, I plan to refactor so that there's only one copy. But that seems useful only in master, so let's use this one-line fix for the back branches. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/31027.1758919078@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0be39b4b1a018aa6cea73b0aee4294fb6f57f58d Modified Files -------------- src/backend/parser/analyze.c | 1 + 1 file changed, 1 insertion(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-09-27 18:29 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-09-27 18:29 pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. Tom Lane <tgl@sss.pgh.pa.us> 2025-09-27 18:29 pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. Tom Lane <tgl@sss.pgh.pa.us> 2025-09-27 18:29 pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. Tom Lane <tgl@sss.pgh.pa.us> 2025-09-27 18:29 pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. Tom Lane <tgl@sss.pgh.pa.us> 2025-09-27 18:29 pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. Tom Lane <tgl@sss.pgh.pa.us> 2025-09-27 18:29 pgsql: Fix missed copying of groupDistinct in transformPLAssignStmt. 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