Re: exposing COPY API

Поиск
Список
Период
Сортировка
От Itagaki Takahiro
Тема Re: exposing COPY API
Дата
Msg-id AANLkTinNsHDpOxpXz0f+UZxJ33vNyV6muGqydsaxBJ_1@mail.gmail.com
обсуждение исходный текст
Ответ на Re: exposing COPY API  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: exposing COPY API  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Fri, Feb 4, 2011 at 12:17, Andrew Dunstan <andrew@dunslane.net> wrote:
>> http://pgbulkload.projects.postgresql.org/pg_bulkload.html#filter
> AFAICT, this doesn't support ragged tables with too many columns, which is
> my prime use case. If it supported variadic arguments in filter functions it
> might come closer.

It will be good improvement for pg_bulkload, but it's off-topic ;-)

> Also, a FDW allows the COPY to be used as a FROM target, giving it great
> flexibility. AFAICT this does not.

BTW, which do you want to improve, FDW or COPY FROM?  If FDW, the better
API would be "raw" version of NextCopyFrom(). For example: bool NextRawFields(CopyState cstate, char **fields, int
*nfields)
The caller FDW has responsibility to form tuples from the raw fields.
If you need to customize how to form the tuples from various fields,
the FDW also need to have such extensibility.

If COPY FROM, we should implement all the features in copy.c
rather than exported APIs.

-- 
Itagaki Takahiro


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Visual Studio 2010/Windows SDK 7.1 support
Следующее
От: Robert Haas
Дата:
Сообщение: Re: We need to log aborted autovacuums