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

On 2018-11-09 18:07, Alvaro Herrera wrote:
> 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.
> 

I am slightly confused now, I thought this landmine was already fixed in
master and what remains is only whether to backport it or not? Which I
guess depends on whether this is classified as a bug or not.

Since the fix has the potential to break current applications and the
documentation is vague about wanted behavior I think it would be
sensible to add a warning only, even if we agree to call it a bug.

Best regards,
Jürgen