Date: Mon, 18 Mar 2019 11:02:15 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: partitioned tables referenced by FKs
Message-ID: <20190318140215.GA23336@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1ecdd004-9ef6-88ad-f5ef-fc221350fef5@lab.ntt.co.jp>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

Hi Amit

On 2019-Mar-18, Amit Langote wrote:

> On 2019/03/15 2:31, Alvaro Herrera wrote:
> > Once I was finished, fixed bugs and tested it, I realized that that was
> > a stupid thing to have done -- because THOSE ARE DIFFERENT CONSTRAINTS.
> > When you say "fk (a) references pk1" you're saying that all the values
> > in fk(a) must appear in pk1.  OTOH when you say "fk references pk" you
> > mean that the values might appear anywhere in pk, not just pk1.
> 
> Sure, then just drop the check trigger that queries only pk1, in favor of
> one that checks pk, that's already in place due to the parent constraint.
> Actually, if one doesn't drop it (that is, by way of dropping the
> constraint that created it), they won't be able to insert into fk anything
> but the subset of rows that pk1 allows as a partition;

That's true, and it is the correct behavior.  What they should be doing
(to prevent the insertion into the referencing relation from failing all
the time) is drop the constraint, as you suggest.

Converting the constraint so that it refers to a completely different
set of permitted values is second-guessing the user about what they
wanted to do; what if we get it wrong, and they really wanted the FK to
reference just exactly the subset of values that they specified, and not
a much larger superset of that?

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