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

Предыдущее
От: Joel Jacobson
Дата:
Сообщение: pov and tsort
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE