Magnus Hagander <mag...@hagander.net> writes:
> On Fri, Jul 1, 2011 at 03:36, Alvaro Herrera <alvhe...@commandprompt.com>
> wrote:
>> I don't understand why it is so much a deal that 9.1 has a different CSV
>> table definition than 9.0 anyway (or any two release combination).
> I don't see that as a big problem either. A file header would make it
> easier to detect for tools though - either by a regular CSV header or
> by just always logging a row with the version number in the first line
> of each file. Making it an actual CSV header has the added benefit of
> being a standard way that non-pg-specific tools know how to deal
> with..
> If it's a pg specific tool, it's likely going to require version
> specific information anyway. This is just one of them. Now, if the
> order and ocntents of the fields is made entirely configurable, that
> basically creates an unlimited number of permutations, and *that* may
> make things really hard on tool developers. And without a header, it
> makes the tool developers work completely impossible - but harder even
> with.
Actually, I thought the argument for a configurable column list was the
other way around. Somebody who wanted to use a tool that only
understood, say, the 9.0 CSV column set could configure his 9.2 database
to output that set, regardless of whether we'd added other column types.
Of course, there are less-complicated ways to provide backwards
compatibility than making the column set fully configurable --- but
providing the feature that way would have other benefits, namely not
having to waste log space and computation effort on columns that a
particular DBA doesn't care about.
No objection here to the idea of adding a CSV header line; just want to
say that there are real reasons to want a configurable column set.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
