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  (Shigeru HANADA <hanada@metrosystems.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: SQL/MED - core functionality
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_execute_from_file, patch v10