Re: SQL/MED - core functionality

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