Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The use case is that it fits in with the way spreadsheets usually do data tables, and many will only allow you to export a whole worksheet (including the heading row) to CSV, not a part of one. Conversely, working with imported data tables will be harder if they lack headings.
Well, if we wanted to *require* a heading row in CSV mode, it would be
relatively foolproof. What I don't like is the proposal for an
independent option; you've got a 50-50 chance of getting it wrong on
import, and that's too high odds for me.
No, we can't require it. Not all will have headers, and then we sure would skip a wanted row. And while my use case referred to spreadsheets, they are not the only sources/recipients of CSVs.
Your 50-50 chance assumes the user knows nothing about the data and uses the switch at random. I think we're entitled to assume the user knows something about their data and uses the switch according to what they have/want.
Right now, if you have a CSV with a header line you have to remove the line with something like 'sed 1d' before importing to PostgreSQL, and when importing from PostgreSQL you have to insert the headers manually after importing the CSV to your spreadsheet. That's got to be annoying and at least as error-prone as providing a switch to accomodate header lines.
Next question: are you imagining that the header row will actually have any semantic significance on input? Will we check the column names? Will we be willing to rearrange the columns if the header row claims the column order is different than the COPY command says?
I'm leaning towards not trying to interpret the line on copy in. Certainly that is the minimalist way to approach this.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
