Re: generic copy options

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Emmanuel Cecchet <manu(at)asterdata(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generic copy options
Date: 2009-09-19 19:10:55
Message-ID: 27188.1253387455@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Emmanuel Cecchet <manu(at)asterdata(dot)com> writes:
> [ latest patch version ]

Do we have consensus on the syntax for this patch? In particular,
what about the question of adding CSV_ to all the CSV-specific option
names? Emmanuel argued that this is necessary to avoid confusion if
we someday introduce other copy formats that have similar options.
However, I think you could easily turn that argument around. Any one
COPY command will surely use just one format, and it seems to me that
forcing different formats to use different names for equivalent options
won't simplify life for anybody. So I'm inclined to think we should
not have the CSV_ prefixes. (I seem to recall that we had exactly
this discussion when the options were introduced the first time, and
settled on not using format-specific option names.)

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:

> + | '(' ')' { $$ = NULL; }
> + | /* EMPTY */ { $$ = NULL; }

I'm not convinced this is a a good idea, and in any case I don't see
it documented. I'm inclined to omit the '(' ')' syntax.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-19 19:26:24 Re: WIP: generalized index constraints
Previous Message Jeff Davis 2009-09-19 18:51:54 Re: WIP: generalized index constraints