Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Date
Msg-id 3097658.1730840765@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails  (Tender Wang <tndrwang@gmail.com>)
Responses Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
List pgsql-hackers
I'm trying to write release notes for commits 53af9491a et al,
and it seems to me that we need to explain how to get out of
the mess that would be left behind by the old DETACH code.
There's no hint about that in the commit message :-(

Clearly, if you have now-inconsistent data, there's little
help for that but to manually fix the inconsistencies.
What I am worried about is how to get to a state where you
have correct catalog entries for the constraint.

Will ALTER TABLE DROP CONSTRAINT on the now stand-alone table
work to clean out the old catalog entries for the constraint?
I'm worried that it will either fail, or go through but remove
triggers on the referenced table that we still need for the
original partitioned table.  If that doesn't work I think we had
better create a recipe for manually removing the detritus.

Once the old entries are gone it should be possible to do ALTER TABLE
ADD CONSTRAINT (with an updated server), and that would validate
your data.  It's the DROP CONSTRAINT part that worries me.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jelte Fennema-Nio
Date:
Subject: Re: Interrupts vs signals
Next
From: Daniel Gustafsson
Date:
Subject: Re: index_delete_sort: Unnecessary variable "low" is used in heapam.c