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 | a90bdd7a44d088a10b2faf5d7cdb85b8e4f0c662 (patch) | |
| tree | a1124cb4c67f9dd3eefc7f924e57e8df7136f092 /src/backend/utils/adt/ruleutils.c | |
| parent | 498ee9ee2f4bc7d79f2d91cdd817b2a8f14a664f (diff) | |
| download | postgresql-a90bdd7a44d088a10b2faf5d7cdb85b8e4f0c662.tar.gz postgresql-a90bdd7a44d088a10b2faf5d7cdb85b8e4f0c662.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/utils/adt/ruleutils.c')
0 files changed, 0 insertions, 0 deletions