Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Tom Lane
Josh Berkus writes: >> >> 4) MAP_HEADER ('column 1'-> 'col_1', 'Date' -> 'input_date' ...) >> >> to cover the case when column names do not match. > Personally, I think that's going way beyond what we want to do with > COPY. I agree --- if you know that much about the incoming data, you might

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Alvaro Herrera
Excerpts from Andrew Dunstan's message of mié jun 20 12:56:52 -0400 2012: > > On 06/20/2012 12:50 PM, Alvaro Herrera wrote: > > 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 col

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Josh Berkus
> > 4) MAP_HEADER ('column 1'-> 'col_1', 'Date' -> 'input_date' ...) > > to cover the case when column names do not match. Personally, I think that's going way beyond what we want to do with COPY. At that point, check out the CSV-array FDW. Of course, if someone writes a WIP patch which imple

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Marc Mamin
> -Ursprüngliche Nachricht- > Von: pgsql-hackers-ow...@postgresql.org im Auftrag von Josh Berkus > Gesendet: Mi 6/20/2012 7:06 > An: pgsql-hackers@postgresql.org > Betreff: Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER ... > (1) is valuabl

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Josh Berkus
> In the past people have asked me to have copy use the CSV header line in > place of supplying a column list in the COPY command. I can certainly > see some utility in that, and I think it might achieve what David wants. > Using that scenario it would be an error to supply an explicit column > li

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Andrew Dunstan
On 06/20/2012 12:50 PM, Alvaro Herrera wrote: 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. That's one of the main use ca

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Andrew Dunstan
On 06/20/2012 12:18 PM, Tom Lane wrote: David Fetter writes: OK, new proposal: COPY FROM (Thanks, Andrew! Must not post while asleep...) should have an option which requires that HEADER be enabled and mandates that the column names in the header match the columns coming in. Has someone got a

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Alvaro Herrera
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 comm

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread David Fetter
On Wed, Jun 20, 2012 at 12:18:45PM -0400, Tom Lane wrote: > David Fetter writes: > > OK, new proposal: > > > COPY FROM (Thanks, Andrew! Must not post while asleep...) should have > > an option which requires that HEADER be enabled and mandates that the > > column names in the header match the co

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Tom Lane
David Fetter writes: > OK, new proposal: > COPY FROM (Thanks, Andrew! Must not post while asleep...) should have > an option which requires that HEADER be enabled and mandates that the > column names in the header match the columns coming in. > Has someone got a better name for this option than

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread David Fetter
On Wed, Jun 20, 2012 at 11:47:14AM -0400, Tom Lane wrote: > David Fetter writes: > > Rather than being totally ignored in the COPY OUT (CSV HEADER) > > case, the header line in should be parsed to establish which > > columns are where and rearranging the output if needed. > > This is not "fix a P

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Andrew Dunstan
On 06/20/2012 11:02 AM, David Fetter wrote: Folks, A co-worker filed a bug against file_fdw where the columns in a FOREIGN TABLE were scrambled on SELECT. It turned out that this comes from the (yes, it's documented, but since it's documented in a place not obviously linked to the bug, it's p

Re: [HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread Tom Lane
David Fetter writes: > Rather than being totally ignored in the COPY OUT (CSV HEADER) case, > the header line in should be parsed to establish which columns are > where and rearranging the output if needed. This is not "fix a POLA violation". This is a non-backwards-compatible new feature, which

[HACKERS] Nasty, propagating POLA violation in COPY CSV HEADER

2012-06-20 Thread David Fetter
Folks, A co-worker filed a bug against file_fdw where the columns in a FOREIGN TABLE were scrambled on SELECT. It turned out that this comes from the (yes, it's documented, but since it's documented in a place not obviously linked to the bug, it's pretty useless) "feature" of COPY CSV HEADER wher