From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: problems with foreign keys on partitioned tables |
Date: | 2019-01-24 16:37:41 |
Message-ID: | 201901241637.joxln3ew2ysm@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-Jan-25, Amit Langote wrote:
> On Fri, Jan 25, 2019 at 12:30 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > 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);
Of course it does when the dependencies are set up -- but in the
approach we just gave up on, those dependencies would not exist.
Anyway, my motivation was that performMultipleDeletions has the
advantage that it collects all objects to be dropped before deleting
anyway, and so the error that a constraint was dropped in a previous
recursion step would not occur.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-01-24 16:45:49 | Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD |
Previous Message | Tom Lane | 2019-01-24 16:35:25 | Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD |