Re: [HACKERS] Performance testing of COPY (SELECT) TO

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Performance testing of COPY (SELECT) TO
Дата
Msg-id 13919.1156787599@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Performance testing of COPY (SELECT) TO  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: [HACKERS] Performance testing of COPY (SELECT)  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Performance testing of COPY (SELECT) TO