Re: exposing COPY API

On 02/08/2011 03:49 AM, Itagaki Takahiro wrote:
> On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>> Here is a patch against the latest revision of file_fdw to exercise this
>> API. It includes some regression tests, and I think apart from one or two
>> small details plus a requirement for documentation, is complete.
> The patch contains a few fixes for typo in the original patch.
> Hanada-san, could you take them into the core file_fdw patch?
>
>> CREATE FOREIGN TABLE jagged_text (
>> t text[]
>> ) SERVER file_server
>> OPTIONS (format 'csv', filename
>> '/home/andrew/pgl/pg_head/contrib/file_fdw/data/jagged.csv', header
>> 'true', textarray 'true');
> There might be another approach -- we could have jagged_file_fdw aside
> from file_fdw, because we cannot support some features in textarray mode
> like force_not_null option and multiple non-text[] columns.
>
> I'll include NextCopyFromRawFields() in COPY API patch to complete
> raw_fields support in CopyState. (Or, we should also revert changes
> related to raw_fields.) However, we'd better postpone jagged csv
> support to 9.2. The design is still under discussion.

Please do include NextCopyFromRawFields(). I think the API is very
limiting without it, but very flexible with it.

I also think that it's better to have contrib examples of the use of an
API than not.

FORCE NOT NULL is much more of an issue for the *non* raw fields case
than the reverse. In the raw fields case the caller can manage it
themselves.

Multiple non-text[] columns strikes me as a red herring. This isn't the
only possible use of NextCopyFromRawFields(), but it is one significant
(and very useful as it stands) use.

cheers

andrew