On Thu, Sep 10, 2009 at 6:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Josh Berkus <j...@agliodbs.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
