> 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.
