Re: Allow COPY's 'text' format to output a header - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Allow COPY's 'text' format to output a header
Date
Msg-id CA+TgmoaZg6J_f1W6-BiPaX8j8SH24aMrrpm=jPKyTPty4GyK1g@mail.gmail.com
Whole thread Raw
In response to Re: Allow COPY's 'text' format to output a header  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 15, 2018 at 12:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> One can imagine extensions of the idea: for example, the header could
>> actually be used to identify the columns, so the column order in the file
>> doesn't matter. There could also be an "AS" syntax to allow the target
>> field names to be different from the field names in the header. I have
>> occasionally found myself wanting to ignore certain columns of the file.
>> But these are all significantly more complicated than just looking at the
>> header and requiring it to match the target field names.
>
> Yeah, and every bit of flexibility you add raises the chance of an
> undetected error.  COPY isn't intended as a general ETL facility,
> so I'd mostly be -1 on adding such things.  But I can see the value
> of confirming that you're copying the right file, and a header match
> check would go a long way towards doing that.

True.

FWIW, I'm +1 on this idea.  I think a header line is a pretty common
need, and if you're exporting a large amount of data, it could be
pretty annoying to have to first run COPY, and then do

(echo blah,blah1,blah2; cat copyoutput.txt)>whatireallywant.txt

There's a lot of value in being able to export from program A
*exactly* what program B wants to import, rather than something that
is close but has to be massaged.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Grigory Smolkin
Date:
Subject: Re: libpq compression
Next
From: Robert Haas
Date:
Subject: Re: Oddity in COPY FROM handling of check constraints on partition tables