Re: COPY enhancements

On Thu, Sep 10, 2009 at 6:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Yes, and GUCs allow users to retrofit this approach onto existing
>> infrastructure without changing their COPY commands.  So there's
>> advantages and disadvantages.  My question was really for the -hackers
>> at large: is this the design we want?  Or, more directly, is the GUC
>> approach anathema to anyone?
>
> Half a dozen interrelated GUCs to control a single command fairly
> screams "bad design" to me; especially the ones that specifically bear
> on the command semantics, rather than being performance settings that
> you could reasonably have system-wide defaults for.  Could we please
> look at doing it via COPY options instead?
>
> It might be time to switch COPY over to a more easily extensible
> option syntax, such as we just adopted for EXPLAIN.

I like this idea, perhaps not surprisingly (for those not following at
home: that was my patch). Unfortunately, it looks to me like there is
no way to do this without overhauling the syntax. If the existing
syntax required a comma between options (i.e. "copy blah to stdout
binary, oids" rather than "copy to stdout binary oids", this would be
pretty straightforward; but it doesn't even allow one).

I wonder if we should consider allowing COPY options to be
comma-separated beginning with 8.5, and then require it in 8.6. Other
options include continuing to support the old syntax for the existing
options, but allowing some new syntax as well and requiring its use
for all new options (this is what we did with EXPLAIN, but there were
only two pre-existing options there), and just changing the syntax
incompatibly and telling users to suck it up. But I'm not sure I like
either of those choices.

...Robert