Re: generic copy options
От | Emmanuel Cecchet |
---|---|
Тема | Re: generic copy options |
Дата | |
Msg-id | 4AB6737D.7070106@asterdata.com обсуждение исходный текст |
Ответ на | Re: generic copy options (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: generic copy options
Re: generic copy options |
Список | 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 по дате отправления: