Re: Allow COPY's 'text' format to output a header
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Isaac Morland <isaac.morland@gmail.com>
Cc: Daniel Verite <daniel@manitou-mail.org>,
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
Simon Muller <samullers@gmail.com>,
Michael Paquier <michael@paquier.xyz>,
David Steele <david@pgmasters.net>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-05-15T16:06:12Z
Lists: pgsql-hackers
Isaac Morland <isaac.morland@gmail.com> writes: > On 15 May 2018 at 10:26, Daniel Verite <daniel@manitou-mail.org> wrote: >> Andrew Dunstan wrote: >>> I'm not necessarily opposed to this, but I'm not certain about the use >>> case either. >> The downside is that it would create the need, when using COPY TO, >> to know whether an input file was generated with or without header, >> and a hazard on mistakes. >> If you say it was and it wasn't, you quietly loose the first row of data. >> If you say it wasn't and in fact it was, either there's a >> datatype mismatch or you quietly get a spurious row of data. > Just to be clear, we're talking about my "header match" feature, not the > basic idea of allowing a header in text format? AFAICS, Daniel's just reacting to the basic idea of a header line. I agree that by itself that's not worth much. However, if we added your proposed option to insist that the column names match during COPY IN, I think that that could have some value. It would allow forestalling one common type of pilot error, ie copying the wrong file entirely. (It'd also prevent copying in data that has the wrong column order, but I think that's a less common scenario. I might be wrong about that.) > 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. regards, tom lane
Commits
-
Fix two issues with HEADER MATCH in COPY
- ca7a0d1d3682 15.0 landed
-
Add header matching mode to COPY FROM
- 072132f04e55 15.0 landed
-
Add HEADER support to COPY text format
- 43f33dc018a4 15.0 landed
-
Fix handling of redundant options with COPY for "freeze" and "header"
- 10c5291cc2c6 14.0 landed