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 1gM3Od-0007H3-MM for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Nov 2018 04:00:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gM3Ob-0003GS-6m for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Nov 2018 04:00:17 +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 1gM3Oa-0003EO-SL for pgsql-hackers@lists.postgresql.org; Mon, 12 Nov 2018 04:00:17 +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 1gM3OT-0006Gu-Nr for pgsql-hackers@lists.postgresql.org; Mon, 12 Nov 2018 04:00:15 +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 wAC3xxC8006677; Sun, 11 Nov 2018 23:00:00 -0500 From: Tom Lane To: Amit Langote cc: Alvaro Herrera , =?UTF-8?Q?J=c3=bcrgen_Strobel?= , Amit Langote , Ashutosh Bapat , 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: <20181109170712.pfn55lab5j7oae4v@alvherre.pgsql> <29152.1541802819@sss.pgh.pa.us> Comments: In-reply-to Amit Langote message dated "Mon, 12 Nov 2018 11:47:27 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6675.1541995199.1@sss.pgh.pa.us> Date: Sun, 11 Nov 2018 22:59:59 -0500 Message-ID: <6676.1541995199@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote writes: > On 2018/11/10 7:33, Tom Lane wrote: >> I'd argue not, actually. I think there is plausible precedent in >> updatable views, where what we use is the defaults associated with the >> view, not the underlying table. Correspondingly, what ought to govern >> in a partitioned insert is the defaults associated with the table actually >> named in the insert command, never mind what its partitions might say. >> That is useful for many situations, and it avoids all the logical >> inconsistencies you get into if you find that the defaults associated >> with some partition would force re-routing elsewhere. > ... > IOW, it might be a good idea to call the ability to set partition-level > defaults a deprecated feature? Not necessarily. They'd apply when you insert directly into a particular partition by name. regards, tom lane