Re: Nasty, propagating POLA violation in COPY CSV HEADER - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Nasty, propagating POLA violation in COPY CSV HEADER
Date
Msg-id 1340210812-sup-8293@alvh.no-ip.org
Whole thread Raw
In response to Re: Nasty, propagating POLA violation in COPY CSV HEADER  (David Fetter <david@fetter.org>)
Responses Re: Nasty, propagating POLA violation in COPY CSV HEADER
List 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 by date:

Previous
From: David Fetter
Date:
Subject: Re: Nasty, propagating POLA violation in COPY CSV HEADER
Next
From: Andres Freund
Date:
Subject: Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node