On Fri, 7 Jan 2011 10:57:17 +0900 Itagaki Takahiro <itagaki.takah...@gmail.com> wrote: > 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)
For the purpose of file_fdw, additional ResetCopyFrom() would be necessary. I'm planning to include such changes in file_fdw patch. Please find attached partial patch for ResetCopyFrom(). Is there anything else which should be done at reset? > 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. IIUC, materizlizing is for tableoid system column. If we could add tts_tableoid into TupleTableSlot, virtual tuple would be enough. In this design, caller can receive results with tts_values/tts_isnull arrays. Regards, -- Shigeru Hanada
20110110-ResetCopyFrom.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
