generic copy options - Mailing list pgsql-hackers

From Robert Haas
Subject generic copy options
Date
Msg-id 603c8f070909122051p68a6644eq8308a07cba38cd9b@mail.gmail.com
Whole thread Raw
Responses Re: generic copy options
List pgsql-hackers
On Fri, Sep 11, 2009 at 5:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Sep 11, 2009 at 5:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> The biggest problem I have with this change is that it's going to
>>> massively break anyone who is using the existing COPY syntax.
>>
>> Why?  We'd certainly still support the old syntax for existing options,
>> just as we did with EXPLAIN.
>
> None of the syntax proposals upthread had that property, which doesn't
> mean we can't do it.  However, we'd need some way to differentiate the
> old syntax from the new one. I guess we could throw an unnecessary set
> of parentheses around the option list (blech), but you have to be able
> to tell from the first token which kind of list you're reading if you
> want to support both sets of syntax.

Here's a half-baked proof of concept for the above approach.  This
probably needs more testing than I've given it, and I haven't
attempted to fix the psql parser or update the documentation, but it's
at least an outline of a solution.  I did patch all the regression
tests to use the new syntax, so you can look at that part of the patch
to get a flavor for it.  If this is broadly acceptable I can attempt
to nail down the details, or someone else is welcome to pick it up.
It's on my git repo as well, as usual.

...Robert

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: CommitFest 2009-09 Starting Soon - still need reviewers!
Next
From: Brendan Jurd
Date:
Subject: Re: WIP: generalized index constraints