Bruce Momjian írta:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> 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
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
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?
If you don't support COPY view TO, at least return an error messsage
that suggests using COPY (SELECT * FROM view). And if you support COPY
VIEW, you are going to have to support a column list for that. Is that
additional complexity in COPY? If so, it might be a reason to just
throw an error on views and do use COPY SELECT.
No, it oes not have any additional complexity,
it uses the same code COPY tablename TO uses.
Seeing that COPY VIEW only supports TO, not FROM, and COPY SELECT
support only TO, not FROM, it seems logical for COPY to just support
relations, and COPY SELECT to be used for views, if we can throw an
error on COPY VIEW to tell people to use COPY SELECT.
The additional hint would be enough if the VIEW case is
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not