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 1h9xMA-0007jd-BE for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Mar 2019 19:40:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h9xM9-0001ZZ-5F for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Mar 2019 19:40:01 +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 1h9xM8-0001ZS-T8 for pgsql-hackers@lists.postgresql.org; Fri, 29 Mar 2019 19:40:00 +0000 Received: from mail-qt1-f193.google.com ([209.85.160.193]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h9xM5-0008M0-HX for pgsql-hackers@postgresql.org; Fri, 29 Mar 2019 19:40:00 +0000 Received: by mail-qt1-f193.google.com with SMTP id w30so3713620qta.8 for ; Fri, 29 Mar 2019 12:39:56 -0700 (PDT) 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:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=79olqedxMSazmphq/Q6YbwUT/WjfIFWecxraoMQwUPw=; b=oTp0H3qg3wUgGxRTiuWgFg2OkpgSjsUyyv0oT41h1rKnl7HBYugSYtAyfmJSTA9zL/ xvH7EjrySfEiJYDpwoQjJsLrzbXkynwQ+N0M1Cw6VEROQ4JGlFgcOYw5CkoNHDRJ3n96 yfrazmN0o8ZXJdj+xIKRVJRudkQ761uA7Dchu6Yl1usBc0vv2c57C4IMi3v33NEUYA4o PUKhMCW+erUeOpy0eGtG4g8jgop6aDpala4RULhCVKH6gPtghk5+hjqRHXY7si3u9AFV ZFtACT63zFKexlIdOZiXfwSqJ3VlCj13eUipdlNJq+DC9G5qObgv1ltom0/8IEb0nE3B oDdQ== X-Gm-Message-State: APjAAAV41vaexQOSHX1sp/fWlSFfyQmzc7hGjrcMrpVKIB4QDncAlmeT ofxk43VOmVOvQzaLHd5BUcO/eQ== X-Google-Smtp-Source: APXvYqzVgJa5NQRCvRX0mBXlKbRPGp03CNQSsLEdkpjgnrQbfkqgrF4dcs0AxASHQH0Ogjty37oH1w== X-Received: by 2002:a0c:812d:: with SMTP id 42mr28719798qvc.68.1553888395179; Fri, 29 Mar 2019 12:39:55 -0700 (PDT) Received: from localhost.localdomain (c-24-61-8-151.hsd1.ma.comcast.net. [24.61.8.151]) by smtp.gmail.com with ESMTPSA id q51sm1724959qtc.38.2019.03.29.12.39.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 12:39:54 -0700 (PDT) Reply-To: jesper.pedersen@redhat.com Subject: Re: partitioned tables referenced by FKs To: Alvaro Herrera , Amit Langote Cc: Pg Hackers , amitlangote09@gmail.com References: <20190328185925.GA23624@alvherre.pgsql> From: Jesper Pedersen Organization: Red Hat Message-ID: <6c6bcb5b-34a2-80ea-07d7-58f1eb7f4a0a@redhat.com> Date: Fri, 29 Mar 2019 15:39:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190328185925.GA23624@alvherre.pgsql> Content-Type: text/plain; charset=windows-1252; 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 Alvaro, On 3/28/19 2:59 PM, Alvaro Herrera wrote: > I ended up revising the dependencies that we give to the constraint in > the partition -- instead of giving it partition-type dependencies, we > give it an INTERNAL dependency. Now when you request to drop the > partition, it says this: > > create table pk (a int primary key) partition by list (a); > create table fk (a int references pk); > create table pk1 partition of pk for values in (1); > > alvherre=# drop table pk1; > ERROR: cannot drop table pk1 because other objects depend on it > DETAIL: constraint fk_a_fkey on table fk depends on table pk1 > HINT: Use DROP ... CASCADE to drop the dependent objects too. > > If you do say CASCADE, the constraint is dropped. Not really ideal (I > would prefer that the drop is prevented completely), but at least it's > not completely bogus. If you do "DROP TABLE pk", it works sanely. > Also, if you DETACH the partition that pg_depend row goes away, so a > subsequent drop of the partition works sanely. > > Fixed the psql issue pointed out by Amit L too. > I ran my test cases for this feature, and havn't seen any issues. Therefore I'm marking 1877 as Ready for Committer. If others have additional feedback feel free to switch it back. Best regards, Jesper