Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation
Dmitry Dolgov <9erthalion6@gmail.com>
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: juergen+postgresql@strobel.info, pgsql-bugs@lists.postgresql.org, PG Bug reporting form <noreply@postgresql.org>
Date: 2018-06-07T14:08:13Z
Lists: pgsql-bugs, pgsql-hackers
> On 7 June 2018 at 15:53, Dmitry Dolgov <9erthalion6@gmail.com> wrote: >> On 6 June 2018 at 10:00, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> Hello. >> >> On 2018/05/28 9:30, PG Bug reporting form wrote: >>> The following bug has been logged on the website: >>> >>> Bug reference: 15212 >>> Logged by: Jürgen Strobel >>> Email address: juergen+postgresql@strobel.info >>> PostgreSQL version: 10.4 >>> Operating system: Debian >>> Description: >>> >>> I found unexpected behavior when playing around with declarative >>> partitioning. >>> First, any way to define defaults on (child) partition tables is silently >>> ignored when inserting into the master table, but not when inserting into >>> the child table. >> >> Hmm, so we provide the ability to specify default values per partition, >> but it is not applied when inserting through the parent. I'd like to hear >> from others on whether we should fix things so that we fill the >> partition's default value for a given column if it's null in the input >> tuple, after that tuple is routed to that partition. It does seem like a >> inconvenience to have to do it through workarounds like a BR trigger. >> >> Actually, default value substitution happens much earlier in the query >> rewrite phase, whereas the partition to actually insert the tuple into >> (that is, tuple routing) is determined much later during the execution of >> the query. So fixing this will require some work. > > Well, since documentation says that partitioning build on top of inheritance, > and for inheritance: > > If the new table explicitly specifies a default value for the column, this > default overrides any defaults from inherited declarations of the column. > > So one may think it should be the same for partitioning as well. "The same for partitioning" - I mean the same approach when in all the situations (whether it's an insert into a parent table or a partition) a partition default value will take precedence.
Commits
-
Revise attribute handling code on partition creation
- e0c05bf4a7e6 11.2 landed
- 705d433fd5e2 12.0 landed
- 21c9e4973cec 10.7 landed