On Tue, Dec 14, 2010 at 15:31, Shigeru HANADA <hanada@metrosystems.co.jp> wrote:
>> - BeginCopyFrom(rel, filename, attnamelist, options) : CopyState
>> - EndCopyFrom(cstate) : void
>> - NextCopyFrom(cstate, OUT values, OUT nulls, OUT tupleOid) : bool
>> - GetCopyExecutorState(cstate) : EState *
>> - CopyFromErrorCallback(arg)
>>
>> Are they enough, Shigeru-san? Note that the internal CopyFrom() is
>> now implemented only with them, so I think file_fdw is also possible.
>
> In addition to above, ResetCopyFrom() is necessary to support nested
> loops which inner node is a ForeignScan.
I think you can add ResetCopyFrom() to the core in your next file_fdw
patch because the function is not used by COPY command.
I'll note other differences between the API and your FileState:
- There are no superuser checks in the exported functions because the restriction should be only at CREATE/ALTER
FOREIGNTABLE. If the superuser grants SELECT privileges to normal users, they should be able to read the file contents.
(Butwe might need to hide the file path.)
- errcontext and values/nulls arrays are not included in CopyState. They will be additionally kept in a holder of the
CopyState.
- You need to pass non-NULL filename. If it is NULL, the server tries to read data from the client.
- The framework supports to read dumped binary files and files with OIDs. If you don't want to support them, please
checkparameters not to include those options.
--
Itagaki Takahiro