Re: problems with foreign keys on partitioned tables

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

In response to

Browse pgsql-hackers by date

  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