Re: SQL/MED - file_fdw
От | Itagaki Takahiro |
---|---|
Тема | Re: SQL/MED - file_fdw |
Дата | |
Msg-id | AANLkTi=-6vSzZiWzcEbjV4zedFyyWxaG_w3mJk0VGT2_@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SQL/MED - file_fdw (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: SQL/MED - file_fdw
|
Список | pgsql-hackers |
On Tue, Dec 14, 2010 at 01:25, Andrew Dunstan <andrew@dunslane.net> wrote: > On 12/13/2010 11:12 AM, Tom Lane wrote: >> I think that exposing the guts of COPY to the open air is a bad idea. I don't want to export the details, too. > 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. BTW, we might have another choice instead of GetCopyExecutorState() because the EState will be used only for ResetPerTupleExprContext() in file_fdw. If NextCopyFrom() returns a HeapTuple instead of values and nulls arrays, we could hide EState in NextCopyFrom(). -- Itagaki Takahiro
Вложения
В списке pgsql-hackers по дате отправления: