Re: Nasty, propagating POLA violation in COPY CSV HEADER

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Nasty, propagating POLA violation in COPY CSV HEADER
Дата
Msg-id 1340210812-sup-8293@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Nasty, propagating POLA violation in COPY CSV HEADER  (David Fetter <david@fetter.org>)
Ответы Re: Nasty, propagating POLA violation in COPY CSV HEADER  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Excerpts from David Fetter's message of mié jun 20 12:43:31 -0400 2012:
> On Wed, Jun 20, 2012 at 12:18:45PM -0400, Tom Lane wrote:

> > In your original proposal, I was rather wondering what should happen
> > if the incoming file didn't have the same set of columns called out
> > in the COPY command's column list.  (That is, while *rearranging*
> > the columns might be thought non-astonishing, I'm less convinced
> > about a copy operation that inserts or defaults columns differently
> > from what the command said should happen.)  If we're just checking
> > for a match, that question goes away.
>
> Let's imagine we have a table foo(id serial, t text, n numeric) and a
> CSV file foo.csv with headers (n, t).  Just to emphasize, the column
> ordering is different in the places where they match.

For the record, IIRC we had one person trying to do this in the spanish
list not long ago.

Another related case: you have a file with headers and columns (n, t, x, y, z)
but your table only has n and t.  How would you tell COPY to discard the
junk columns?  Currently it just complains that they are there.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Nasty, propagating POLA violation in COPY CSV HEADER
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node