From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Nasty, propagating POLA violation in COPY CSV HEADER |
Date: | 2012-06-20 16:50:46 |
Message-ID: | 1340210812-sup-8293@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-06-20 16:53:01 | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node |
Previous Message | David Fetter | 2012-06-20 16:43:31 | Re: Nasty, propagating POLA violation in COPY CSV HEADER |