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 1gheMS-0001ac-Cb for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Jan 2019 17:43:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gheMR-0005jE-2l for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Jan 2019 17:43:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gheMQ-0005j7-Sj for pgsql-bugs@lists.postgresql.org; Thu, 10 Jan 2019 17:43:18 +0000 Received: from mail-qt1-f182.google.com ([209.85.160.182]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gheMO-0007jR-4T for pgsql-bugs@lists.postgresql.org; Thu, 10 Jan 2019 17:43:18 +0000 Received: by mail-qt1-f182.google.com with SMTP id u47so14246285qtj.6 for ; Thu, 10 Jan 2019 09:43:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ev0JrKBDC5mCf1HRCdAowPmembb4VEXTF+voqlAM5BQ=; b=c45236BPImRX/4fciR8lCJIVaGrRCkdO6/KMbI46xiohd+vUBf3Oe/8Vh1MUL3m/AI jiURpof2AeF0me0Ky2kpXBN2j0jDvTOW0F8nwfni5CwASDZRpyEGZrD6rnIMa4/NgKcP MXfDpE8FUYW7mPcaf6sr43QagKn23S1zaRIUiyMHbSFeh7Kpi7pM7x03QkkMY95hMd0P ee9HLc/5/rx0H4gdc0pxjsX4izT7NZcQ6/4vGNSqnMYUS4L1F5qC8UODgNB5529+R7Ct b1CSBZFYjVB/lR043agZcT9t/nqVhr4/FOhVvBvfMT2MMWn38D/zSKFWiV4tBcrN5jek gZtA== X-Gm-Message-State: AJcUukebcz3TjxaCrlk8mgJWLQ7xNCXRdHqDDxzRODKb6nXGl5tdOHNw kugLIPAavNXNkUnUByBMmLAV+QbvGNo= X-Google-Smtp-Source: ALg8bN4H3Fn0nMAlIpBD7/vLY70NYiWcSG/gEjkfJIzGbcXHOEzS2ybgvJpFJywW54o69ixqJbmqIw== X-Received: by 2002:ac8:4884:: with SMTP id i4mr10430253qtq.219.1547142193579; Thu, 10 Jan 2019 09:43:13 -0800 (PST) Received: from localhost.localdomain (c-24-61-8-151.hsd1.ma.comcast.net. [24.61.8.151]) by smtp.gmail.com with ESMTPSA id n71sm45063341qkh.59.2019.01.10.09.43.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jan 2019 09:43:12 -0800 (PST) Reply-To: jesper.pedersen@redhat.com Subject: Re: BUG #15587: Partitions with ALTER TABLE ADD CONSTRAINT To: Alvaro Herrera , pgsql-bugs@lists.postgresql.org References: <201901101711.ngskkvwyqgr6@alvherre.pgsql> From: Jesper Pedersen Organization: Red Hat Message-ID: <3e406e7f-b3df-7f9d-fcf3-1201f3c87903@redhat.com> Date: Thu, 10 Jan 2019 12:43:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <201901101711.ngskkvwyqgr6@alvherre.pgsql> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 1/10/19 12:11 PM, Alvaro Herrera wrote: > On 2019-Jan-10, PG Bug reporting form wrote: >> Removing ONLY from the ALTER command makes the index correct. > > I'm not clear what problem you're reporting. If you use ONLY, then the > command doesn't cascade to create the index on partitions, and the index > is marked invalid. If you add the constraint to each partition and > ALTER INDEX ATTACH PARTITION, the index on t1 should become valid when > every partition of the table has its index. > 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 ? Best regards, Jesper