Re: SQL/MED - file_fdw

On Mon, Dec 20, 2010 at 20:42, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> I added comments and moved some setup codes for COPY TO to BeginCopyTo()
> for maintainability. CopyTo() still contains parts of initialization,
> but I've not touched it yet because we don't need the arrangement for now.

I updated the COPY FROM API patch.
- GetCopyExecutorState() is removed because FDWs will use their own context.

The patch just rearranges codes for COPY FROM to export those functions.
It also modifies some of COPY TO codes internally for code readability.
- BeginCopyFrom(rel, filename, attnamelist, options)
- EndCopyFrom(cstate)
- NextCopyFrom(cstate, OUT values, OUT nulls, OUT tupleOid)
- CopyFromErrorCallback(arg)

Some items to be considered:
- BeginCopyFrom() could receive filename as an option instead of a separated
argument. If do so, file_fdw would be more simple, but it's a change only for
file_fdw. COPY commands in the core won't be improved at all.
- NextCopyFrom() returns values/nulls arrays rather than a HeapTuple. I expect
the caller store the result into tupletableslot with ExecStoreVirtualTuple().
It is designed for performance, but if the caller always needs an materialized
HeapTuple, HeapTuple is better for the result type.

--
Itagaki Takahiro