From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED - core functionality |
Date: | 2010-11-26 16:16:32 |
Message-ID: | 10586.1290788192@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Radosław Smogura | 2010-11-26 16:20:47 | Re: Workarounds for getBinaryStream returning ByteArrayInputStream on bytea |
Previous Message | Bruce Momjian | 2010-11-26 16:11:58 | libpq/Makefile cleanup abandoned |