Re: exposing COPY API

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: exposing COPY API
Date: 2011-02-04 03:43:16
Message-ID: AANLkTinNsHDpOxpXz0f+UZxJ33vNyV6muGqydsaxBJ_1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 4, 2011 at 12:17, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Scott Marlowe 2011-02-04 03:48:46 Re: [HACKERS] Slow count(*) again...
Previous Message Robert Haas 2011-02-04 03:41:43 Re: Visual Studio 2010/Windows SDK 7.1 support