From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Jürgen Strobel <juergen+postgresql@strobel.info>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation
Date: Fri, 09 Nov 2018 17:33:39 -0500
Message-ID: <29152.1541802819@sss.pgh.pa.us> (raw)
In-Reply-To: <20181109170712.pfn55lab5j7oae4v@alvherre.pgsql>
References: <20181109170712.pfn55lab5j7oae4v@alvherre.pgsql>
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> 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.
I'd argue not, actually. I think there is plausible precedent in
updatable views, where what we use is the defaults associated with the
view, not the underlying table. Correspondingly, what ought to govern
in a partitioned insert is the defaults associated with the table actually
named in the insert command, never mind what its partitions might say.
That is useful for many situations, and it avoids all the logical
inconsistencies you get into if you find that the defaults associated
with some partition would force re-routing elsewhere.
In any case, you can't make this happen without basically blowing up
default processing altogether. Defaults are currently expanded by the
planner, and pretty early too. To make it work like the OP wishes,
we'd have to insert them sometime late in the executor.
> In any case it seems really hard to see this is as a bug that we would
> fix in back-branches.
Backwards compatibility considerations would prevent that in any case.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, juergen+postgresql@strobel.info, Langote_Amit_f8@lab.ntt.co.jp, amitlangote09@gmail.com, ashutosh.bapat@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Subject: Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation
In-Reply-To: <29152.1541802819@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox