Re: BUG #15212: Default values in partition tables don't work asexpected and allow NOT NULL violation - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: BUG #15212: Default values in partition tables don't work asexpected and allow NOT NULL violation
Date
Msg-id 20181109170712.pfn55lab5j7oae4v@alvherre.pgsql
Whole thread Raw
In response to BUG #15212: Default values in partition tables don't work as expectedand allow NOT NULL violation  (Jürgen Strobel <juergen+postgresql@strobel.info>)
Responses Re: BUG #15212: Default values in partition tables don't work asexpected and allow NOT NULL violation  (Jürgen Strobel <juergen+postgresql@strobel.info>)
Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Alternative to \copy in psql modelled after \g
Next
From: "Daniel Verite"
Date:
Subject: Re: Alternative to \copy in psql modelled after \g