On Fri, 18 Oct 2024 16:50:59 +0200 Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> On 2024-Sep-26, Jehan-Guillaume de Rorthais wrote: > > > REL_14_STABLE backport doesn't seem trivial, so I'll wait for some > > feedback, review & decision before going further down in backpatching. > > Hi, thanks for these patches. I have made some edits of my own. In the > end I decided that I quite liked the new structure of the > addFkConstraint() function and friends. Yes, I especially like the fact that addFkRecurseReferencing() and addFkRecurseReferenced() have now the same logic/behavior. > I added a bunch of comments and changed names somewhat. checked. > Also, I think the benefit of the refactoring is > more obvious when all patches are squashed together, so I did that. OK. > For branch 14, I opted to make it delete the constraints on detach. > This isn't ideal but unless somebody wants to spend a lot more time on > this, it seems the best we can do. Leaving broken constraints around > seems worse. Keep that in mind, and move ahead to the next level: self-FK on partitioned table! ;-) https://www.postgresql.org/message-id/flat/20230707175859.17c91538%40karst#0dc7b8afd8b780899021bbb075598250 > […] > > I spent some time going through your test additions and ended up with > your functions in this form: > […] > > However, in the end I think this is a very good technique to verify that > the fix works correctly, but it's excessive to include these results in > the tests forevermore. So I've left them out for now. Maybe we should > reconsider on the older branches? The point here was to make sure futur work/refactoring don't forget/break anything in the catalog representation of FK on partitions. Regards,
