Re: generic copy options - Mailing list pgsql-hackers

From Emmanuel Cecchet
Subject Re: generic copy options
Date
Msg-id 4AB6737D.7070106@asterdata.com
Whole thread Raw
In response to Re: generic copy options  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: generic copy options
Re: generic copy options
List pgsql-hackers
Tom Lane wrote:
> Emmanuel Cecchet <manu@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: generic copy options
Next
From: Tom Lane
Date:
Subject: Re: generic copy options