On Wed, Mar 11, 2020 at 8:53 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > > On Thu, Feb 27, 2020 at 10:22 PM Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > > > * The "root" is not necessarily the root partitioned table, but instead > > it's the table that was named in the command. Because of this, we don't > > need to acquire locks on the tables, since the executor already has the > > tables open and locked (thus they cannot be modified by concurrent > > commands). > > I believe this is because of the partition level constraints on the > table that was named in the command would catch any violation in the > partition key change in the levels above that table. > > Will it be easier to subject the new tuple to the partition level > constraints themselves and report if those are violated. See > RelationGetPartitionQual() for getting partition constraints. This > function includes partition constraints from all the levels so in your > function you don't have to walk up the partition tree. It includes > constraints from the level above the table that was named in the > command, but that might be fine. We will catch the error earlier and > may be provide a better error message.
I realized that this will implement the third option in your original proposal, not the second one. I suppose that's fine too? -- Best Wishes, Ashutosh Bapat
