Re: Confusing docs about GetForeignUpperPaths in fdwhandler.sgml

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Confusing docs about GetForeignUpperPaths in fdwhandler.sgml
Date: 2016-11-04 02:59:47
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2016/11/03 23:39, Robert Haas wrote:
> On Wed, Oct 26, 2016 at 3:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> A larger issue is that I think the API itself is poorly designed, as
>> I stated awhile ago (<31706(dot)1457547166(at)sss(dot)pgh(dot)pa(dot)us>)

I agree on that point. I plan to rewrite direct modify using upper
planner path-ification; I think we would no longer need the planner API
PlanDirectModify, but I expect the executor/explain APIs (ie,
BeginDirectModify, IterateDirectModify, EndDirectModify, and
ExplainDirectModify) would be still useful after that rewrite. Before
that, however, I'd like to work on extend postgres_fdw so as to handle
more cases such as UPDATE/DELETE on a join and INSERT, with the existing

> I'd really be quite happy to see you take a more active hand
> in the FDW discussions; clearly, you've got a lot of understanding of
> that area that is pretty much unique to you. I'd even support an
> effort to rewrite the work that has already been done in a form more
> to your liking, but I think you'd need to actually pay attention to
> the threads on a somewhat regular basis in order that to be practical.


Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2016-11-04 03:00:15 Re: Gather Merge
Previous Message Peter Eisentraut 2016-11-04 02:05:49 Re: Logical Replication WIP