Re: fix possible optimizations in ATExecAttachPartition()

From: Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fix possible optimizations in ATExecAttachPartition()
Date: 2017-06-13 21:13:18
Message-ID: CAOgcT0MQ48ixyTdsGOf_kApyqnewBG9p10bAAag7sQQPfCuAJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 14, 2017 at 2:12 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Jun 13, 2017 at 5:22 AM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > Yeah, I was thinking the same while writing the patch posted on the
> thread
> > "A bug in mapping attributes in ATExecAttachPartition()" [1]. That patch
> > adds the break you mention in 2, but didn't do anything about point 1.
> >
> > In any case, +1 to your patch. I'll rebase if someone decides to commit
> > it first.
>
> If the patch I posted in
> https://www.postgresql.org/message-id/CA%2BTgmoYmW9VwCWDpe7eXUxeKmAKOxm
> g8itgFkB5UTQTq4SnTjQ%40mail.gmail.com
> gets committed, all of this code will be gone entirely, so this will
> be moot. If we decide to repair the existing broken logic rather than
> ripping it out entirely then this is probably a good idea, but I hope
> that's not what happens.
>

That seems a better option to me too.
+1

Regards,
Jeevan Ladhe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-06-13 21:18:01 Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)
Previous Message Piotr Stefaniak 2017-06-13 21:13:12 Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)