Re: generic copy options
От | Emmanuel Cecchet |
---|---|
Тема | Re: generic copy options |
Дата | |
Msg-id | 4AB66C0E.2050900@asterdata.com обсуждение исходный текст |
Ответ на | Re: generic copy options (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: generic copy options
|
Список | pgsql-hackers |
Tom Lane wrote: > No, I don't think so. Suppose I write > > COPY ... (xml_header on) > > If HEADER isn't actually an option supported by XML format, what I will > get here is an "unknown option" error, which conveys just about nothing > --- is it really an unsupported combination, or did I just misspell the > option name? Well, I don't see why you would write that if the option is not documented. Usually as a user, when I need to use a command, I look at the doc/man page and use the options that are indicated, I don't try to invent new options. That should prevent the kind of scenario you describe here: > If we go with the other way then I would expect > > COPY ... (xml, header on) > > to draw a specific "HEADER is not supported in XML format" error. > Of course, that will require some extra code to make it happen. > So you could argue that format-specific option names are easier > from the lazy programmer's viewpoint. But I don't believe the > argument that they're better from the user's viewpoint. > Here you will force every format to use the same set of options 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. I don't think this is a great design and that it will be easy to extend. Emmanuel -- Emmanuel Cecchet Aster Data Systems Web: http://www.asterdata.com
В списке pgsql-hackers по дате отправления: