Date: Fri, 9 Nov 2018 14:07:12 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: =?utf-8?Q?J=C3=BCrgen?= Strobel <juergen+postgresql@strobel.info>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>,
	Amit Langote <amitlangote09@gmail.com>,
	Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: BUG #15212: Default values in partition tables don't work as
 expected and allow NOT NULL violation
Message-ID: <20181109170712.pfn55lab5j7oae4v@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <67125a48-0e0f-4f7e-6d02-e312fe13f7fe@strobel.info>
User-Agent: NeoMutt/20180716
Precedence: bulk

On 2018-Nov-09, Jürgen Strobel wrote:

> Regarding your example, what I expected is that *both* inserts would
> consistently result in a tuple of (1, 42) since p should route the
> insert to p1 and use p1's defaults. The current inconsistent behavior is
> the heart of the bug.

I think that would be sensible behavior, as long as the partition
doesn't override values for the partitioning column -- i.e. if the
default values don't re-route the tuple to another partition, I think we
should use the partition's default rather than the parent.  This says we
should expand defaults after routing.  However, can we really route if
we haven't expanded defaults?  In general, we may be lacking values for
some columns of the partition key.  Another point: if we've already
expanded defaults when processing at the parent level, when we reach the
partition we don't know which values are still missing default
expansion, or which defaults coming from the parent ought to be
re-expanded.

So this looks to be a bit of a landmine.

In any case it seems really hard to see this is as a bug that we would
fix in back-branches.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services