Shigeru HANADA <hanada@metrosystems.co.jp> writes:
> I'll revise the patch along the discussion. Before starting code work,
> please let me summarize the discussion.
> * Generally, we should keep FDWs away from PostgreSQL internals,
> such as TupleTableSlot.
> * FDW should have planner hook which allows FDW to create FDW-specific
> plan (FdwPlan in Heikki's proposal) for a scan on a foreign table.
> * FdwPlan, a part of ForeignScan plan node, should be able to be
> copied in generic way because plans would be copied into another
> memory context during caching. It might be better to represent
> FdwPlan with Node or List.
> * FdwExecutionState, a part of ForeignScanState, should be used
> instead of ForeignScanState to remove executor details from FDW
> implementation.
> # ISTM that FdwExecutionState would be replace FdwReply.
FWIW, I think that the notion that FDW can be "kept away from Postgres
internals" is ridiculous on its face. Re-read the above list and ask
yourself exactly which of the bullet points above are not talking about
being hip-deep in Postgres internals. In particular, arbitrarily
avoiding use of TupleTableSlot is silly. It's a fundamental part of
many executor APIs.
It would be a good idea to avoid use of internals in the wire protocol
to another Postgres database; but the interfaces to the local database
can hardly avoid that, and we shouldn't bend them out of shape to meet
entirely-arbitrary requirements about what to use or not use.
regards, tom lane
