Re: SQL/MED - file_fdw

On Tue, Dec 14, 2010 at 15:31, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)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