Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjUUw-0004HQ-0W for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Jan 2019 19:35:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gjUUu-0000qT-PW for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Jan 2019 19:35:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjUUu-0000qC-Bm for pgsql-bugs@lists.postgresql.org; Tue, 15 Jan 2019 19:35:40 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjUUq-0003UJ-PF for pgsql-bugs@lists.postgresql.org; Tue, 15 Jan 2019 19:35:39 +0000 Received: by mail-qt1-x841.google.com with SMTP id u47so4359425qtj.6 for ; Tue, 15 Jan 2019 11:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=fPdLJKEU3z04Z9BbVms5v/tcUPeaMvernrZu41PBYMY=; b=p0ESdrhWgMldmU6+jW1aLy/F1LJ7teMRxfRO31usrnyA9I8MVm49fS5mZyoRNcWQho LH74n52SgHujFd5l/rche3yCPHfqCYpr3qPJm85e7DfMCExV1hpBxQN1Vbe2HElIeNRv pIGSvxkMABemRpVW5/CoRSBZhD4IL9mQqYA3vNyoy2LeILult/sRHIohif+isPFm/Snc 0bdVHXHNWynUs3Ee+MCyJ2oMorHjvC+Ki5GsHkuk1ygg9I0C7mjMG8dt2/BPBhXDuWyr 5mDUoaUs0muLIf00e3/T9NcN1IWd6ILOtsmlXFlXAXxpTqvXfrM7FpUY1V3xqFD7oAJr quKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=fPdLJKEU3z04Z9BbVms5v/tcUPeaMvernrZu41PBYMY=; b=seggGghrDXuOGmkW/0kfqyCACqR24cse2qV9lNEh+VzjGYSdqtTgmsMCJRpgydQcGl eVdz2At0l99sHbdXYpYEnwOnFBJ7QZr/4L8x7ALjHCaGhlrfh7OryWzVvUkserIJDkD0 FeEyvEfQCSAF++sJhBWlam/aQTU9Pn43oVGJH64WklvDN12XMxlOSbQcqVd5SJfnXiPV upgUpK6NR5HGmIgOVlJIH4i6rJBQMr7faLIbncd/kFLD4qik029RjP0boiub84hhjp1V XweSnWRzjCHKoea60z0IKdS93e+XsgTtfy/xiikYzarS3LwDeHCUt/M2pg5J+yjQFDba Vd0g== X-Gm-Message-State: AJcUuke/CQL1lRlnS35N4iAhpfrw/84dsvJYHAFP14Jq+VkURhVLHNy2 ZmnEElCVSaYQmpOknq3BcGZ0fQl9mNYuiIIP6yK8EGYLlgZ4791xzVnSFpuXdpx3IzcptbUVMq4 HvTEQeOZ8l5zcUfNV5Yupx2X+7s/Oknw8/SiUCCO3vcMuLzhCXGFk3ndZerBNYQOQ2+7UYAry5Y 9uOqRGbcfJUg== X-Google-Smtp-Source: ALg8bN7Cr8MmfSekGkRtKsWj1EV3B1Te4ucfWENXzwxHa0GSnLzE5gIIWx2IQ8QWRj71NaoHes5ZJA== X-Received: by 2002:a0c:9b9f:: with SMTP id o31mr4122657qve.230.1547580935392; Tue, 15 Jan 2019 11:35:35 -0800 (PST) Received: from alvin.alvh.no-ip.org ([201.186.80.67]) by smtp.gmail.com with ESMTPSA id c11sm42853728qtn.95.2019.01.15.11.35.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 15 Jan 2019 11:35:34 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 733CAC41; Tue, 15 Jan 2019 16:35:32 -0300 (-03) Date: Tue, 15 Jan 2019 16:35:32 -0300 From: Alvaro Herrera To: Tom Lane Cc: Jesper Pedersen , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15587: Partitions with ALTER TABLE ADD CONSTRAINT Message-ID: <201901151935.zfadrzvyof4k@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2815.1547577776@sss.pgh.pa.us> User-Agent: NeoMutt/20180716-1013-2c1e88 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Jan-15, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Jan-10, Jesper Pedersen wrote: > >> However, when you use ADD CONSTRAINT FOREIGN KEY you can't use ONLY, so > >> would it be a good idea to make ADD CONSTRAINT UNIQUE behave the same way, > >> i.e. error out ? > > > I haven't investigated this angle. It seems more complex than just a > > simple bugfix, right? > > Wouldn't that be throwing away the entire point of the ONLY behavior, > ie to allow the component indexes to be built one at a time, without > holding locks across the whole partition tree? I now see that Jesper was talking about a completely different thing than I was thinking. I agree with you there -- it makes no sense to reject that command ... particularly because pg_dump uses it. What was on my head ("can we add ONLY to ADD FOREIGN KEY?") was the idea that it'd be useful to construct the foreign keys in partitions, one by one, and as a final step you construct a foreign key in the partitioned table and then attach each FK in partition to the master one. Right now, adding the foreign key in the parent table just creates duplicates in the partitions, which is silly. create table foo (a int primary key); create table barp (a int) partition by list (a); create table barp1 partition of barp for values in (1); create table barp2 partition of barp for values in (2); alter table barp1 add foreign key (a) references foo; alter table barp2 add foreign key (a) references foo; At this point, the partitions have one FK each, and it would be neat to merge them as a unit, creating a parent constraint. But if you do: alter table barp add foreign key (a) references foo; you end up with two FKs in each partition. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services