Re: generic copy options

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