Emmanuel Cecchet <m...@asterdata.com> writes: > That would assume that the semantic of the other options (header, quote, > espace, ...) is exactly the same for each format. Otherwise this will be > a nightmare to document.
Well, sure, we should pick a different name for an option that means something significantly different. But for options that do mean approximately the same thing in different formats, it doesn't seem helpful to require different names to be used. > If we don't prefix with CSV, I guess that some users will spend some > time to figure out that NULL is not a format option but FORCE NOT NULL > is. If an option is only supported by one format (let's say XML) we will > have to document every time which options are supported by which format > which would be much easier and intuitive is options were readily > prefixed by the format name. 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? 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers