Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Jürgen Strobel <juergen+postgresql@strobel.info>, Amit Langote <amitlangote09@gmail.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-11-12T04:17:35Z
Lists: pgsql-bugs, pgsql-hackers
On 2018/11/12 12:59, Tom Lane wrote: > Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes: >> On 2018/11/10 7:33, Tom Lane wrote: >>> I'd argue not, actually. I think there is plausible precedent in >>> updatable views, where what we use is the defaults associated with the >>> view, not the underlying table. Correspondingly, what ought to govern >>> in a partitioned insert is the defaults associated with the table actually >>> named in the insert command, never mind what its partitions might say. >>> That is useful for many situations, and it avoids all the logical >>> inconsistencies you get into if you find that the defaults associated >>> with some partition would force re-routing elsewhere. > >> ... >> IOW, it might be a good idea to call the ability to set partition-level >> defaults a deprecated feature? > > Not necessarily. They'd apply when you insert directly into a particular > partition by name. Yes. Maybe, we should document that the partition default are not honored when inserting through the parent. Thanks, Amit
Commits
-
Revise attribute handling code on partition creation
- e0c05bf4a7e6 11.2 landed
- 705d433fd5e2 12.0 landed
- 21c9e4973cec 10.7 landed