Re: exposing COPY API
От | Andrew Dunstan |
---|---|
Тема | Re: exposing COPY API |
Дата | |
Msg-id | 4D510C5F.6070804@dunslane.net обсуждение исходный текст |
Ответ на | Re: exposing COPY API (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Список | pgsql-hackers |
On 02/08/2011 03:49 AM, Itagaki Takahiro wrote: > On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan<andrew@dunslane.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
В списке pgsql-hackers по дате отправления: