Re: SQL/MED - file_fdw
От | Shigeru HANADA |
---|---|
Тема | Re: SQL/MED - file_fdw |
Дата | |
Msg-id | 20101214153135.A5F4.6989961C@metrosystems.co.jp обсуждение исходный текст |
Ответ на | Re: SQL/MED - file_fdw (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Ответы |
Re: SQL/MED - file_fdw
|
Список | pgsql-hackers |
On Tue, 14 Dec 2010 12:01:36 +0900 Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > On Tue, Dec 14, 2010 at 01:25, Andrew Dunstan <andrew@dunslane.net> wrote: > > On 12/13/2010 11:12 AM, Tom Lane wrote: > > In that case I guess I'll need to do what Shigeru-san has done, and copy > > large parts of copy.c. > > I found file_fdw would require the executor state in CopyState and > the error callback function. I revised the patch to export them. > Now 5 functions are exported from copy.c: > > - 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. On the other hand, I think that MarkPos()/RestrPos() wouldn't be necessary until ForeignScan supports ordered output. ForeignScan can't become direct child of MergeJoin because ForeignScan is not an ordered scan, at least in current SQL/MED implementation. Regards, -- Shigeru Hanada
В списке pgsql-hackers по дате отправления: