Re: [HACKERS] Performance testing of COPY (SELECT) TO - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] Performance testing of COPY (SELECT) TO
Date
Msg-id 13919.1156787599@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Performance testing of COPY (SELECT) TO  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [HACKERS] Performance testing of COPY (SELECT)
List pgsql-patches
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Zoltan Boszormenyi wrote:
>> My v8 had the syntax support for
>>    COPY (SELECT ...) (col1, col2, ...) TO
>> and it was actually working. In your v9
>> you rewrote the syntax parsing so that
>> feature was lost in translation.

> Interesting.  I didn't realize this was possible -- obviously I didn't
> test it (did you have a test for it in the regression tests?  I may have
> missed it).  In fact, I deliberately removed the column list from the
> grammar, because it can certainly be controlled inside the SELECT, so I
> thought there was no reason the support controlling it in the COPY
> column list.

I would vote against allowing a column list here, because it's useless
and it strikes me as likely to result in strange syntax error messages
if the user makes any little mistake.  What worries me is that the
above looks way too nearly like a function call, which means that for
instance if you omit a right paren somewhere in the SELECT part, you're
likely to get a syntax error that points far to the right of the actual
mistake.  The parser could also mistake the column list for a table-alias
column list.

Specifying a column list with a view name is useful, of course, but
what is the point when you are writing out a SELECT anyway?

            regards, tom lane

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO