Re: SQL/MED - file_fdw
Itagaki Takahiro <itagaki.takahiro@gmail.com>
From: Itagaki Takahiro <itagaki.takahiro@gmail.com>
To: pgsql-hackers@postgresql.org
Cc: Shigeru HANADA <hanada@metrosystems.co.jp>
Date: 2011-01-07T01:57:17Z
Lists: pgsql-hackers
Attachments
- copy_export-20111007.patch (application/octet-stream) patch
On Mon, Dec 20, 2010 at 20:42, Itagaki Takahiro <itagaki.takahiro@gmail.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