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 1gMM5B-0000bo-He for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Nov 2018 23:57:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gMM58-0005Zi-Gn for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Nov 2018 23:57:26 +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 1gMM58-0005Zb-6q for pgsql-hackers@lists.postgresql.org; Mon, 12 Nov 2018 23:57:26 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gMM55-0002Xi-Q2 for pgsql-hackers@lists.postgresql.org; Mon, 12 Nov 2018 23:57:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id wACNvJ2F010300; Mon, 12 Nov 2018 18:57:19 -0500 From: Tom Lane To: =?UTF-8?Q?J=c3=bcrgen_Strobel?= cc: Alvaro Herrera , Amit Langote , PostgreSQL Hackers Subject: Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation In-reply-to: References: <20181112140051.yv5m77esq5jz6rkg@alvherre.pgsql> <5662.1542040384@sss.pgh.pa.us> Comments: In-reply-to =?UTF-8?Q?J=c3=bcrgen_Strobel?= message dated "Tue, 13 Nov 2018 00:06:45 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10298.1542067039.1@sss.pgh.pa.us> Date: Mon, 12 Nov 2018 18:57:19 -0500 Message-ID: <10299.1542067039@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk =?UTF-8?Q?J=c3=bcrgen_Strobel?= writes: > On 2018-11-12 17:33, Tom Lane wrote: >> I'm not entirely convinced that I buy that argument, especially not in >> a case like this where it introduces logical inconsistencies where there >> otherwise wouldn't be any. > I think I missed something, what are the *introduced* logical problems? What to do if a partition introduces a default value that would force re-routing to some other partition. > Apart from implementation issues the only logical problems I see are if > you allow to change defaults of the partition key columns, and these are > problematic (nonsensical really) in either case. Just claiming that it's nonsensical doesn't fix the problem. Also, it is neither problematic nor nonsensical for the root to provide defaults for partition key columns. So if we go this route, we are giving up useful behavior (key-column defaults on the root) for useless behavior (key-column defaults on the partitions). regards, tom lane