On Tue, Dec 14, 2010 at 15:31, Shigeru HANADA <han...@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 FOREIGN TABLE. If the superuser grants SELECT privileges to normal users, they should be able to read the file contents. (But we 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 check parameters not to include those options. -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
