On 2017/06/08 2:07, Robert Haas wrote:
> On Wed, Jun 7, 2017 at 1:23 AM, Amit Langote
> wrote:
>> On 2017/06/07 11:57, Amit Langote wrote:
>>> How about we export ExecPartitionCheck() out of execMain.c and call it
>>> just before ExecFindPartition() using the root
On Wed, Jun 7, 2017 at 1:23 AM, Amit Langote
wrote:
> On 2017/06/07 11:57, Amit Langote wrote:
>> How about we export ExecPartitionCheck() out of execMain.c and call it
>> just before ExecFindPartition() using the root table's ResultRelInfo?
>
> Turns out there
On 2017/06/07 11:57, Amit Langote wrote:
> How about we export ExecPartitionCheck() out of execMain.c and call it
> just before ExecFindPartition() using the root table's ResultRelInfo?
Turns out there wasn't a need to export ExecPartitionCheck after all.
Instead of calling it from
On 2017/06/07 1:19, Robert Haas wrote:
> On Mon, Jun 5, 2017 at 1:02 AM, Amit Langote
> wrote:
>> On 2017/06/03 1:56, Robert Haas wrote:
>>> On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote
>>> wrote:
Attached patch makes
On Mon, Jun 5, 2017 at 1:02 AM, Amit Langote
wrote:
> On 2017/06/03 1:56, Robert Haas wrote:
>> On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote
>> wrote:
>>> Attached patch makes InitResultRelInfo() *always* initialize the
>>>
On 2017/06/03 1:56, Robert Haas wrote:
> On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote
> wrote:
>> Attached patch makes InitResultRelInfo() *always* initialize the
>> partition's constraint, that is, regardless of whether insert/copy is
>> through the parent or
On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote
wrote:
> Attached patch makes InitResultRelInfo() *always* initialize the
> partition's constraint, that is, regardless of whether insert/copy is
> through the parent or directly on the partition. I'm wondering if
>
On 2017/06/02 10:36, Robert Haas wrote:
> On Thu, Jun 1, 2017 at 6:05 PM, Tom Lane wrote:
>> Without having checked the code, I imagine the reason for this is
>> that BEFORE triggers are fired after tuple routing occurs.
>
> Yep.
>
>> Re-ordering that seems problematic,
On Thu, Jun 1, 2017 at 6:05 PM, Tom Lane wrote:
> Without having checked the code, I imagine the reason for this is
> that BEFORE triggers are fired after tuple routing occurs.
Yep.
> Re-ordering that seems problematic, because what if you have different
> triggers on
Robert Haas writes:
> I just discovered that a BEFORE trigger can allow data into a
> partition that violates the relevant partition constraint. This is
> bad.
Without having checked the code, I imagine the reason for this is
that BEFORE triggers are fired after tuple
I tried to debug this, and I see that while the target partition index is
correctly
found in ExecInsert(), somehow the resultRelInfo->ri_PartitionCheck is NIL,
this
is extracted from array mstate->mt_partitions.
This prevents execution of constraints in following code snippet in
ExecInsert():
/*
I just discovered that a BEFORE trigger can allow data into a
partition that violates the relevant partition constraint. This is
bad.
Here is an example:
rhaas=# create or replace function t() returns trigger as $$begin
new.a := 2; return new; end$$ language plpgsql;
CREATE FUNCTION
rhaas=#
12 matches
Mail list logo