On Fri, Nov 26, 2010 at 11:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
But there's probably some value in minimizing the number of
unnecessary interfaces that get exposed to the plugins. There's no
help for the fact that the FDWs are going to need about Datums, but do
we gain anything by making them also know about TupleTableSlot? If
so, fine; if not, don't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company