diff options
| author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2024-08-08 19:35:13 -0400 |
|---|---|---|
| committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2024-08-08 19:35:13 -0400 |
| commit | 344f9f5e2b181331ead4b7bcd792216ecc5f2946 (patch) | |
| tree | b5d8279e96b1275acb4172cb6e9c608e96576925 /src/backend/commands | |
| parent | 28b953f26343105ebf3a1a212092e2c3c0bb0914 (diff) | |
| download | postgresql-344f9f5e2b181331ead4b7bcd792216ecc5f2946.tar.gz postgresql-344f9f5e2b181331ead4b7bcd792216ecc5f2946.zip | |
Refuse ATTACH of a table referenced by a foreign key
Trying to attach a table as a partition which is already on the
referenced side of a foreign key on the partitioned table that it is
being attached to, leads to strange behavior: we try to clone the
foreign key from the parent to the partition, but this new FK points to
the partition itself, and the mix of pg_constraint rows and triggers
doesn't behave well.
Rather than trying to untangle the mess (which might be possible given
sufficient time), I opted to forbid the ATTACH. This doesn't seem a
problematic restriction, given that we already fail to create the
foreign key if you do it the other way around, that is, having the
partition first and the FK second.
Backpatch to all supported branches.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Reviewed-by: Tender Wang <tndrwang@gmail.com>
Discussion: https://postgr.es/m/18541-628a61bc267cd2d3@postgresql.org
Diffstat (limited to 'src/backend/commands')
| -rw-r--r-- | src/backend/commands/tablecmds.c | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index 937d47417e4..d219d220691 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -10771,6 +10771,23 @@ CloneFkReferencing(List **wqueue, Relation parentRel, Relation partRel) { ForeignKeyCacheInfo *fk = lfirst(cell); + /* + * Refuse to attach a table as partition that this partitioned table + * already has a foreign key to. This isn't useful schema, which is + * proven by the fact that there have been no user complaints that + * it's already impossible to achieve this in the opposite direction, + * i.e., creating a foreign key that references a partition. This + * restriction allows us to dodge some complexities around + * pg_constraint and pg_trigger row creations that would be needed + * during ATTACH/DETACH for this kind of relationship. + */ + if (fk->confrelid == RelationGetRelid(partRel)) + ereport(ERROR, + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), + errmsg("can't attach table \"%s\" as a partition which is referenced by foreign key \"%s\"", + RelationGetRelationName(partRel), + get_constraint_name(fk->conoid)))); + clone = lappend_oid(clone, fk->conoid); } |