Date: Tue, 19 Mar 2019 09:13:11 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>,
	Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: partitioned tables referenced by FKs
Message-ID: <20190319121311.GA11582@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+HiwqHLa06WANZYfix3OdbaESec61ye5Dwv0sgymoEBQJAu2Q@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On 2019-Mar-19, Amit Langote wrote:

> On Tue, Mar 19, 2019 at 8:49 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > On 2019-Mar-19, Amit Langote wrote:
> >
> > > Will it suffice or be OK if we skipped invoking the pre-drop callback for
> > > objects that are being "indirectly" dropped?  I came up with the attached
> > > patch to resolve this problem, if that idea has any merit.  We also get
> > > slightly better error message as seen the expected/foreign_key.out changes.
> >
> > I don't think this works ... consider putting some partition in a
> > different schema and then doing DROP SCHEMA CASCADE.
> 
> Ah, I did test DROP SCHEMA CASCADE, but only tested putting the top
> table into the schema, not a partition.

:-(

I think this is fixable by using a two-step strategy where we first
compile a list of constraints being dropped, and in the second step we
know to ignore those when checking partitions that are being dropped.
Now, maybe the order of objects visited guarantees that the constraint
is seen (by drop) before each corresponding partition, and in that case
we don't need two steps, just one.  I'll have a look at that.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services