Date: Mon, 21 Jan 2019 13:29:44 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	Jesper Pedersen <jesper.pedersen@redhat.com>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15587: Partitions with ALTER TABLE ADD CONSTRAINT
Message-ID: <201901211629.gu3plkjjqefw@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <24217a8f-5f9b-8bcc-1698-ff38921addee@lab.ntt.co.jp>
User-Agent: NeoMutt/20180716-1013-2c1e88
Precedence: bulk

On 2019-Jan-21, Amit Langote wrote:

> Sorry about the noise.  I agree with the committed approach.

Great, thanks for checking.

> With this,
> ALTER TABLE ADD FOREIGN KEY's inheritance recursion path now looks
> completely different from ALTER TABLE ADD CHECK's, but that's fine.
> Actually, if we had the same "clone" approach for check constraints, which
> both checks if a child already has the constraint being cloned and creates
> one if not, we could do away with errors like the following:
> 
> create table p (a int, constraint check_a check (a > 0)) partition by list
> create table p1 (a int);
> alter table p attach partition p1 for values in (1);
> ERROR:  child table is missing constraint "check_a"
> 
> But of course that would be a different feature.

Heh, I wasn't aware that this failed in this silly way.  But yeah,
that's a different feature and we would certainly not backpatch a fix
for it.

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