Re: generic copy options

Tom Lane wrote:
> Emmanuel Cecchet <manu(at)asterdata(dot)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