Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation
Дата
Msg-id 10299.1542067039@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #15212: Default values in partition tables don't work asexpected and allow NOT NULL violation  (Jürgen Strobel <juergen+postgresql@strobel.info>)
Ответы Re: BUG #15212: Default values in partition tables don't work asexpected and allow NOT NULL violation  (Jürgen Strobel <juergen+postgresql@strobel.info>)
Список pgsql-hackers
=?UTF-8?Q?J=c3=bcrgen_Strobel?= <juergen+postgresql@strobel.info> writes:
> On 2018-11-12 17:33, Tom Lane wrote:
>> 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.

> I think I missed something, what are the *introduced* logical problems?

What to do if a partition introduces a default value that would force
re-routing to some other partition.

> Apart from implementation issues the only logical problems I see are if
> you allow to change defaults of the partition key columns, and these are
> problematic (nonsensical really) in either case.

Just claiming that it's nonsensical doesn't fix the problem.  Also, it
is neither problematic nor nonsensical for the root to provide defaults
for partition key columns.  So if we go this route, we are giving up
useful behavior (key-column defaults on the root) for useless behavior
(key-column defaults on the partitions).

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Decimal64 and Decimal128
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Removal of unnecessary CommandCounterIncrement() when doing ONCOMMIT DELETE ROWS