Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> 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