|From:||Jürgen Strobel <juergen+postgresql(at)strobel(dot)info>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Cc:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2018-11-12 17:33, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> One of the guiding principles that I think we should hold for
>> partitioning is that operating directly into the partition should be
>> seen as only an optimization compared to inserting into the parent table
>> -- thus it should not behave differently. Applying different default
>> values depending on where you're inserting into goes counter to that
> 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?
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.
|Next Message||Tom Lane||2018-11-12 23:57:19||Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation|
|Previous Message||Romero, Yonatan||2018-11-12 21:10:54||Re: BUG #15499: pg_dump does not read connection URL from environment variable|
|Next Message||Tom Lane||2018-11-12 23:07:20||Re: [Bug Fix]ECPG: cancellation of significant digits on ECPG|
|Previous Message||Andres Freund||2018-11-12 23:04:59||Re: [HACKERS] Decimal64 and Decimal128|