Tom Lane wrote:
Emmanuel Cecchet <m...@asterdata.com> writes:
Here you will force every format to use the same set of options
How does this "force" any such thing?
As far as I understand it, every format will have to handle every format
options that may exist so that they can either implement it or throw an
error.
and if
someone introduces a new option, you will have to modify all other
formats to make sure they throw an error telling the user that this
option is not supported.
Well, if we do it your way then we will instead need a collection of
code to throw errors for combinations like (xml on, csv_header on).
I don't really see any improvement there.
That would argue in favor of a format option that defines the format.
Right now I find it bogus to have to say (csv on, csv_header on). If
csv_header is on that should imply csv on.
The only problem I have is that it is not obvious what options are
generic COPY options and what are options of an option (like format
options).
So maybe a tradeoff is to differentiate format specific options like in:
(delimiter '.', format csv, format_header, format_escape...)
This should also make clear if someone develops a new format what
options need to be addressed.
Emmanuel
PS: I don't know why but as I write this message I already feel that Tom
hates this new proposal :-D
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
