Re: Needless additional partition check in INSERT?

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Subject: Re: Needless additional partition check in INSERT?
Date: 2018-05-17 05:23:04
Message-ID: 08583f5e-3492-9d5d-f627-4bfac03e3b33@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018/05/17 14:15, David Rowley wrote:
> On 10 May 2018 at 21:56, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>> On 10 May 2018 at 17:42, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> Patch is good.
>>>
>>> The cause of this oversight is the lack of comments to explain the
>>> original coding, so we need to correct that in this patch, please.
>>
>> Thanks for looking.
>>
>> Yeah, the comments do need work. In order to make it a bit easier to
>> document I changed the way that check_partition_constr is set. This is
>> now done with an if/else if/else clause for both COPY and INSERT.
>>
>> Hopefully, that's easier to understand and prevents further mistakes.
>>
>> Patch attached.
>
> While this does not cause any undesired behaviour, I think it's quite
> clear that it's unintended, so I've added this to the v11 open items
> list.
>
> If there's consensus that this is not the case then we can remove it
> from the list. I've just added it to ensure that a proper evaluation
> has been done.

Yeah, we should try to fix what I too think may just have been an
oversight during PG 11 development.

Thanks,
Amit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-05-17 05:23:37 Re: PATCH: pgbench - option to build using ppoll() for larger connection counts
Previous Message Amit Langote 2018-05-17 05:19:44 Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers