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)
|
Список | 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 по дате отправления: