Re: exposing COPY API - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: exposing COPY API
Date
Msg-id AANLkTinNsHDpOxpXz0f+UZxJ33vNyV6muGqydsaxBJ_1@mail.gmail.com
Whole thread Raw
In response to Re: exposing COPY API  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: exposing COPY API  (Andrew Dunstan <andrew@dunslane.net>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Visual Studio 2010/Windows SDK 7.1 support
Next
From: Robert Haas
Date:
Subject: Re: We need to log aborted autovacuums