| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Jürgen Strobel <juergen+postgresql(at)strobel(dot)info>, 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 |
| Date: | 2018-11-12 16:33:04 |
| Message-ID: | 5662.1542040384@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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
> principle.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Derek Nelson | 2018-11-12 20:00:32 | Re: Tables created WITH OIDS cannot be dumped/restored properly |
| Previous Message | Alvaro Herrera | 2018-11-12 14:00:51 | Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-11-12 16:50:53 | Re: NULL handling in exconfig deconstruction |
| Previous Message | Tom Lane | 2018-11-12 16:21:10 | Re: Uninterruptible long planning of a query with too many WHERE clauses |