Re: generic copy options

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>
>> ... A related question is whether we
>> should replace the "CSV" option with a "FORMAT" option for which one
>> of the possible choices is "CSV" (much as we did with EXPLAIN).
>>
>
> That might be a good idea --- otherwise we'd need some ad-hoc code
> to check that only one format option has been selected. On the other
> hand, it wouldn't be all that much code; and it would be a rather larger
> change from previous behavior than we were contemplating to start with.
> Comments anyone?
>
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.
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.
If you look at the COPY documentation in the error logging patch, if we
strip the error_logging prefix, it is going to be very confusing.
But I am willing to let Tom choose whatever he prefers as his birthday
gift ;-)

>>> One other minor point is that the patch introduces an empty-list
>>> syntax for individual option values, but then treats it the same
>>> as specifying nothing:
>>>
>
>
>> It seemed like a good idea because if you can do force_quote (a, b, c)
>> and force_quote (a, b) you might think that you could also do
>> force_quote (). Particularly for the sake of people generating SQL
>> automatically by some means, it seems like this might simplify life.
>> But possibly it shouldn't evaluate to the same value, so that you
>> can't write OIDS () to mean the same thing as OIDS ON.
>>
>
> Yeah, that type of scenario was why I didn't like it. I am not
> impressed by the empty-list argument, either. We don't support empty
> lists with that sort of syntax in most other places, so why here?
> There are counter-precedents even in the syntax of COPY itself:
> you can't write "()" for an empty column name list, and you can't
> write "()" for an empty copy_generic_option_list.
>
Well this one was in Robert's initial patch and I left it as is. I don't
have any strong opinion for or against it.

Emmanuel

--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com