Re: exposing COPY API
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Itagaki Takahiro <itagaki.takahiro@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-04T07:53:55Z
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 →
-
Allow the low level COPY routines to read arbitrary numbers of fields.
- af1a614ec6d0 9.1.0 cited
On 02/03/2011 10:43 PM, Itagaki Takahiro wrote: > >> 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. The problem with COPY FROM is that nobody's come up with a good syntax for allowing it as a FROM target. Doing what I want via FDW neatly gets us around that problem. But I'm quite OK with doing the hard work inside the COPY code - that's what my working prototype does in fact. One thing I'd like is to to have file_fdw do something we can't do another way. currently it doesn't, so it's nice but uninteresting. cheers andrew