Horton

Re: exposing COPY API

Itagaki Takahiro <itagaki.takahiro@gmail.com>

View thread
From: Itagaki Takahiro <itagaki.takahiro@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-04T03:43:16Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow the low level COPY routines to read arbitrary numbers of fields.

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