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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: BUG #15212: Default values in partition tables don't work asexpected and allow NOT NULL violation
Дата
Msg-id 20181109170712.pfn55lab5j7oae4v@alvherre.pgsql
обсуждение исходный текст
Ответ на BUG #15212: Default values in partition tables don't work as expectedand 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>)
Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2018-Nov-09, Jürgen Strobel wrote:

> Regarding your example, what I expected is that *both* inserts would
> consistently result in a tuple of (1, 42) since p should route the
> insert to p1 and use p1's defaults. The current inconsistent behavior is
> the heart of the bug.

I think that would be sensible behavior, as long as the partition
doesn't override values for the partitioning column -- i.e. if the
default values don't re-route the tuple to another partition, I think we
should use the partition's default rather than the parent.  This says we
should expand defaults after routing.  However, can we really route if
we haven't expanded defaults?  In general, we may be lacking values for
some columns of the partition key.  Another point: if we've already
expanded defaults when processing at the parent level, when we reach the
partition we don't know which values are still missing default
expansion, or which defaults coming from the parent ought to be
re-expanded.

So this looks to be a bit of a landmine.

In any case it seems really hard to see this is as a bug that we would
fix in back-branches.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Alternative to \copy in psql modelled after \g
Следующее
От: "Daniel Verite"
Дата:
Сообщение: Re: Alternative to \copy in psql modelled after \g