Re: problems with foreign keys on partitioned tables

On Fri, Jan 25, 2019 at 12:30 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> On Fri, Jan 25, 2019 at 12:08 AM Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
> > On 2019-Jan-24, Amit Langote wrote:
> >
> > > Thinking more on this, my proposal to rip dependencies between parent and
> > > child constraints altogether to resolve the bug I initially reported is
> > > starting to sound a bit overambitious especially considering that we'd
> > > need to back-patch it (the patch didn't even consider index constraints
> > > properly, creating a divergence between the behaviors of inherited foreign
> > > key constraints and inherited index constraints). We can pursue it if
> > > only to avoid bloating the catalog for what can be achieved with little
> > > bit of additional code in tablecmds.c, but maybe we should refrain from
> > > doing it in reaction to this particular bug.
> >
> > While studying your fix it occurred to me that perhaps we could change
> > things so that we first collect a list of objects to drop, and only when
> > we're done recursing perform the deletion, as per the attached patch.
> > However, this fails for the test case in your 0001 patch (but not the
> > one you show in your email body), because you added a stealthy extra
> > ingredient to it: the constraint in the grandchild has a different name,
> > so when ATExecDropConstraint() tries to search for it by name, it's just
> > not there, not because it was dropped but because it has never existed
> > in the first place.
>
> Doesn't the following performDeletion() at the start of
> ATExecDropConstraint(), through findDependentObject()'s own recursion,
> take care of deleting *all* constraints, including those of?

Meant to say: "...including those of the grandchildren?"

> /*
> * Perform the actual constraint deletion
> */
> conobj.classId = ConstraintRelationId;
> conobj.objectId = con->oid;
> conobj.objectSubId = 0;
>
> performDeletion(&conobj, behavior, 0);

Thanks,
Amit