Re: Foreign keys and partitioned tables
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-30T03:19:53Z
Lists: pgsql-hackers
Attachments
Here's an updated version. After wasting some time trying to resolve "minor last minute issues", I decided to reduce the scope for now: in the current patch, it's allowed to have foreign keys in partitioned tables, but it is not possible to have foreign keys that point to partitioned tables. I have split out some preliminary changes that intended to support FKs referencing partitioned tables; I intend to propose that for early v12, to avoid spending any more time this commitfest on that. Yes, I'm pretty disappointed about that. 0001 prohibits having foreign keys pointing to partitioned tables, as discussed above. 0002 is a fixup for a bug in the row triggers patch: I had a restriction earlier that triggers declared internal were not cloned, and I seem to have lost it in rebase. Reinstate it. 0003 is the matter of interest. This is essentially the same code I posted earlier, rebased to the committed row triggers patch, with a few minor bug fixes and some changes in the regression tests to try and make them more comprehensive, including leaving a partitioned table with an FK to test that the whole pg_dump thing works via the pg_upgrade test. An important change is that when a table containing data is attached as a partition, the data is verified to satisfy the constraint via the regular alter table phase 3 code. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Restore erroneously removed ONLY from PK check
- 7d7c99790b2a 11.0 landed
-
Foreign keys on partitioned tables
- 3de241dba86f 11.0 landed
-
Don't clone internal triggers to partitions
- 851f4b4e1430 11.0 landed
-
Pass correct TupDesc to ri_NullCheck() in Assert
- cd5005bc12d0 11.0 landed