pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Repair misbehavior with duplicate entries in FK SET column lists 4+ messages / 1 participants [nested] [flat]
* pgsql: Repair misbehavior with duplicate entries in FK SET column lists @ 2025-04-05 00:11 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-04-05 00:11 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Repair misbehavior with duplicate entries in FK SET column lists. Since v15 we've had an option to apply a foreign key constraint's ON DELETE SET DEFAULT or SET NULL action to just some of the referencing columns. There was not a check for duplicate entries in the list of columns-to-set, though. That caused a potential memory stomp in CreateConstraintEntry(), which incautiously assumed that the list of columns-to-set couldn't be longer than the number of key columns. Even after fixing that, the case doesn't work because you get an error like "multiple assignments to same column" from the SQL command that is generated to do the update. We could either raise an error for duplicate columns or silently suppress the dups, and after a bit of thought I chose to do the latter. This is motivated by the fact that duplicates in the FK column list are legal, so it's not real clear why duplicates in the columns-to-set list shouldn't be. Of course there's no need to actually set the column more than once. I left in the fix in CreateConstraintEntry() too, just because it didn't seem like such low-level code ought to be making assumptions about what it's handed. Bug: #18879 Reported-by: Yu Liang <luy70@psu.edu> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18879-259fc59d072bd4d7@postgresql.org Backpatch-through: 15 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f5069f0264eedd71ee138b872b131a2974017b6a Modified Files -------------- src/backend/catalog/pg_constraint.c | 3 ++- src/backend/commands/tablecmds.c | 35 ++++++++++++++++++++++++------- src/test/regress/expected/foreign_key.out | 3 ++- src/test/regress/sql/foreign_key.sql | 3 ++- 4 files changed, 34 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Repair misbehavior with duplicate entries in FK SET column lists @ 2025-04-05 00:11 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-04-05 00:11 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Repair misbehavior with duplicate entries in FK SET column lists. Since v15 we've had an option to apply a foreign key constraint's ON DELETE SET DEFAULT or SET NULL action to just some of the referencing columns. There was not a check for duplicate entries in the list of columns-to-set, though. That caused a potential memory stomp in CreateConstraintEntry(), which incautiously assumed that the list of columns-to-set couldn't be longer than the number of key columns. Even after fixing that, the case doesn't work because you get an error like "multiple assignments to same column" from the SQL command that is generated to do the update. We could either raise an error for duplicate columns or silently suppress the dups, and after a bit of thought I chose to do the latter. This is motivated by the fact that duplicates in the FK column list are legal, so it's not real clear why duplicates in the columns-to-set list shouldn't be. Of course there's no need to actually set the column more than once. I left in the fix in CreateConstraintEntry() too, just because it didn't seem like such low-level code ought to be making assumptions about what it's handed. Bug: #18879 Reported-by: Yu Liang <luy70@psu.edu> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18879-259fc59d072bd4d7@postgresql.org Backpatch-through: 15 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5e6e97fbf4031de0e7c84d87a002c0eef2ca7abe Modified Files -------------- src/backend/catalog/pg_constraint.c | 3 ++- src/backend/commands/tablecmds.c | 35 ++++++++++++++++++++++++------- src/test/regress/expected/foreign_key.out | 3 ++- src/test/regress/sql/foreign_key.sql | 3 ++- 4 files changed, 34 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Repair misbehavior with duplicate entries in FK SET column lists @ 2025-04-05 00:11 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-04-05 00:11 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Repair misbehavior with duplicate entries in FK SET column lists. Since v15 we've had an option to apply a foreign key constraint's ON DELETE SET DEFAULT or SET NULL action to just some of the referencing columns. There was not a check for duplicate entries in the list of columns-to-set, though. That caused a potential memory stomp in CreateConstraintEntry(), which incautiously assumed that the list of columns-to-set couldn't be longer than the number of key columns. Even after fixing that, the case doesn't work because you get an error like "multiple assignments to same column" from the SQL command that is generated to do the update. We could either raise an error for duplicate columns or silently suppress the dups, and after a bit of thought I chose to do the latter. This is motivated by the fact that duplicates in the FK column list are legal, so it's not real clear why duplicates in the columns-to-set list shouldn't be. Of course there's no need to actually set the column more than once. I left in the fix in CreateConstraintEntry() too, just because it didn't seem like such low-level code ought to be making assumptions about what it's handed. Bug: #18879 Reported-by: Yu Liang <luy70@psu.edu> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18879-259fc59d072bd4d7@postgresql.org Backpatch-through: 15 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/43b8e6c4abfb632bbff5b3a26dc39bf3f188afff Modified Files -------------- src/backend/catalog/pg_constraint.c | 3 ++- src/backend/commands/tablecmds.c | 35 ++++++++++++++++++++++++------- src/test/regress/expected/foreign_key.out | 3 ++- src/test/regress/sql/foreign_key.sql | 3 ++- 4 files changed, 34 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Repair misbehavior with duplicate entries in FK SET column lists @ 2025-04-05 00:11 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-04-05 00:11 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Repair misbehavior with duplicate entries in FK SET column lists. Since v15 we've had an option to apply a foreign key constraint's ON DELETE SET DEFAULT or SET NULL action to just some of the referencing columns. There was not a check for duplicate entries in the list of columns-to-set, though. That caused a potential memory stomp in CreateConstraintEntry(), which incautiously assumed that the list of columns-to-set couldn't be longer than the number of key columns. Even after fixing that, the case doesn't work because you get an error like "multiple assignments to same column" from the SQL command that is generated to do the update. We could either raise an error for duplicate columns or silently suppress the dups, and after a bit of thought I chose to do the latter. This is motivated by the fact that duplicates in the FK column list are legal, so it's not real clear why duplicates in the columns-to-set list shouldn't be. Of course there's no need to actually set the column more than once. I left in the fix in CreateConstraintEntry() too, just because it didn't seem like such low-level code ought to be making assumptions about what it's handed. Bug: #18879 Reported-by: Yu Liang <luy70@psu.edu> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/18879-259fc59d072bd4d7@postgresql.org Backpatch-through: 15 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/fb3a77fd9db03610c5af219d9ddfb499d77df505 Modified Files -------------- src/backend/catalog/pg_constraint.c | 3 ++- src/backend/commands/tablecmds.c | 35 ++++++++++++++++++++++++------- src/test/regress/expected/foreign_key.out | 3 ++- src/test/regress/sql/foreign_key.sql | 3 ++- 4 files changed, 34 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-04-05 00:11 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-04-05 00:11 pgsql: Repair misbehavior with duplicate entries in FK SET column lists Tom Lane <tgl@sss.pgh.pa.us> 2025-04-05 00:11 pgsql: Repair misbehavior with duplicate entries in FK SET column lists Tom Lane <tgl@sss.pgh.pa.us> 2025-04-05 00:11 pgsql: Repair misbehavior with duplicate entries in FK SET column lists Tom Lane <tgl@sss.pgh.pa.us> 2025-04-05 00:11 pgsql: Repair misbehavior with duplicate entries in FK SET column lists 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