Robert Haas <robertmhaas@gmail.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?
>> 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.
regards, tom lane
