Re: SQL/MED - file_fdw
От | Itagaki Takahiro |
---|---|
Тема | Re: SQL/MED - file_fdw |
Дата | |
Msg-id | AANLkTinpXTR4WOXAEEa_A6y3U9_+cT+v1b222HJPgm5k@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SQL/MED - file_fdw (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Ответы |
Re: SQL/MED - file_fdw
Re: SQL/MED - file_fdw |
Список | pgsql-hackers |
On Mon, Dec 20, 2010 at 20:42, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > I added comments and moved some setup codes for COPY TO to BeginCopyTo() > for maintainability. CopyTo() still contains parts of initialization, > but I've not touched it yet because we don't need the arrangement for now. I updated the COPY FROM API patch. - GetCopyExecutorState() is removed because FDWs will use their own context. The patch just rearranges codes for COPY FROM to export those functions. It also modifies some of COPY TO codes internally for code readability. - BeginCopyFrom(rel, filename, attnamelist, options) - EndCopyFrom(cstate) - NextCopyFrom(cstate, OUT values, OUT nulls, OUT tupleOid) - CopyFromErrorCallback(arg) Some items to be considered: - BeginCopyFrom() could receive filename as an option instead of a separated argument. If do so, file_fdw would be more simple, but it's a change only for file_fdw. COPY commands in the core won't be improved at all. - NextCopyFrom() returns values/nulls arrays rather than a HeapTuple. I expect the caller store the result into tupletableslot with ExecStoreVirtualTuple(). It is designed for performance, but if the caller always needs an materialized HeapTuple, HeapTuple is better for the result type. -- Itagaki Takahiro
Вложения
В списке pgsql-hackers по дате отправления: