Re: [PATCHES] WITH DELIMITERS in COPY

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