Re: [HACKERS] Add support for tuple routing to foreign partitions

Michael Paquier <michael.paquier@gmail.com>

From: Michael Paquier <michael.paquier@gmail.com>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Maksim Milyutin <milyutinma@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2017-11-30T03:51:37Z
Lists: pgsql-hackers
On Fri, Nov 24, 2017 at 10:03 PM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> (2017/10/27 20:00), Etsuro Fujita wrote:
>>
>> Please find attached an updated version of the patch.
>
>
> Amit rebased this patch and sent me the rebased version off list. Thanks for
> that, Amit!
>
> One thing I noticed I overlooked is about this change I added to
> make_modifytable to make a valid-looking plan node to pass to
> PlanForeignModify to plan remote insert to each foreign partition:
>
> +               /*
> +                * The column list of the child might have a different
> column
> +                * order and/or a different set of dropped columns than that
> +                * of its parent, so adjust the subplan's tlist as well.
> +                */
> +               tlist = preprocess_targetlist(root,
> +                                             child_parse->targetList);
>
> This would be needed because the FDW might reference the tlist.  Since
> preprocess_targetlist references root->parse, it's needed to replace that
> with the child query before calling that function, but I forgot to do that.
> So I fixed that.  Attached is an updated version of the patch.

Moved to next CF as this got no reviews and the last version is fresh.
-- 
Michael


Commits

  1. Allow insert and update tuple routing and COPY for foreign tables.

  2. Refactor PgFdwModifyState creation/destruction into separate functions.