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

From Tom Lane
Subject Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation
Date
Msg-id 10299.1542067039@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #15212: Default values in partition tables don't work asexpected and 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>)
List pgsql-hackers
=?UTF-8?Q?J=c3=bcrgen_Strobel?= <juergen+postgresql@strobel.info> 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Decimal64 and Decimal128
Next
From: Michael Paquier
Date:
Subject: Re: Removal of unnecessary CommandCounterIncrement() when doing ONCOMMIT DELETE ROWS