Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers