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