Re: de-deduplicate code in DML execution hooks in postgres_fdw

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: de-deduplicate code in DML execution hooks in postgres_fdw
Date: 2018-07-19 11:35:40
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

(2018/07/19 17:52), Ashutosh Bapat wrote:
> On Thu, Jul 19, 2018 at 2:05 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> +1 for the general idea. (Actually, I also thought the same thing before.)
>> But since this is definitely a matter of PG12, ISTM that it's wise to work
>> on this after addressing the issue in [1]. My concern is: if we do this
>> refactoring now, we might need two patches for fixing the issue in case of
>> backpatching as the fix might need to change those executor functions.
> The only thing in [1] that would conflict with this patch is the 0002
> (and possibly 0001) patch in [2]. We haven't yet decided anything
> about whether those patches can be back-patched or not. I think it's
> going to take much longer time for the actual solution to arise. But
> we don't have to wait for it to commit this patch as well as 0001 and
> 0002 patches in [2]

I've just started catching up the discussions in [1], so I don't think I
understand those fully, but it appears that we haven't yet reached a
consensus on what to do for that issue.

> because a. the larger solution is not likely to be
> back-patchable b. it's going to take much longer time. We don't have
> any estimate about how much longer it's going to take.

I don't understand the solution yet, so I'll study about that.

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2018-07-19 11:42:06 Re: GiST VACUUM
Previous Message Masahiko Sawada 2018-07-19 11:29:51 Re: [WIP] [B-Tree] Retail IndexTuple deletion