Gavin Sherry <swm@linuxworld.com.au> writes:
> Now that I look at this patch again I don't think I like the
> syntax.
> COPY [BINARY] <relation> [WITH OIDS] TO | FROM <file> [[USING DELIMITERS |
> WITH DELIMITER] <delimiter> [WITH NULL AS <char>]
> It isn't very elegant.
> 1) I forced the parser to be able to handle multiple WITHs, but that
> doesn't mean its right.
It seems wrong to me. The other statements that use WITH use only one
WITH to introduce a list of option clauses.
I can't remember why I didn't propose a better
> syntax back then, such as:
> ... [WITH [DELIMITER <delimiter>,] [NULL AS <char>]]
The other statements you might model this on don't use commas either.
The closest thing to the precedents would be
... [WITH copyoption [copyoption ...]]
copyoption := DELIMITER delim | NULL AS nullstring | etc
To get some modicum of backwards compatibility, we could allow either
DELIMITER or DELIMITERS as a copy-option keyword, and we could allow
USING as a substitute for the initial WITH. This still won't be quite
backwards compatible for statements that use both of the old option
clauses; how worried are we about that? Maybe we could persuade the
parser to handle
... [ WITH | USING copyoption [ [WITH] copyoption ... ]]
but my that seems ugly.
> 2) Given (1), Why does WITH OIDS belong where it is now? Why not have it
> as an 'option' at the end?
Historical precedent, mainly. Changing this would break existing
pg_dump files, so I'm not eager to do it. (AFAIR pg_dump never uses
DELIMITERS nor NULL AS, so it doesn't care if you change that part
of the syntax.)
If we were working in a green field I'd vote for moving BINARY into the
WITH-options too, but we aren't. Again that seems too likely to break
things in the name of a small amount of added consistency.
regards, tom lane
