On Fri, Feb 4, 2011 at 12:17, Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
