Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:

Remember that we were talking about supporting views, not tables.  And
if a view uses a slow query then you are in immediate danger of having a
slow COPY.  This may not be a problem but it needs to be discussed and
an agreement must be reached before introducing such a change (and not
during feature freeze).
COPY relname TO meant tables _and_ views to me.
My previous tsting showed no difference between
COPY table TO and COPY (SELECT * FROM table) TO.
Similarly a slow query defined in the view should show
no difference between COPY view TO and

The difference is that we are giving a very clear distinction between a
table and a view.  If we don't support the view in the direct COPY, but
instead insist that it be passed via a SELECT query, then the user will
be aware that it may be slow.

It still can be documented with supporting
the COPY view TO syntax.

But COPY view (col1, col2, ...) TO may still be
useful even if the COPY (SELECT ...) (col1, col2, ...) TO
is pointless. [1]

"relname" at this point may mean anything -- are you supporting
sequences and toast tables as well?

Well, not really. :-)

And remember, Bruce put the original COPY view TO
patch into the unapplied queue, without the SELECT

All sort of junk enters that queue so that's not an argument.  (Not
meant to insult Bruce -- I'm just saying that he doesn't filter stuff.
We've had patches rejected from the queue before plenty of times.)

OK. :-)

Rewriting COPY view TO internally to
COPY (SELECT * FROM view) TO is very
straightforward, even if you think it's ugly.
BTW, why is it ugly if I call raw_parser()
from under src/backend/parser/*.c ?
It is on a query distinct to the query the parser
is currently running. Or is it the recursion
that bothers you? It's not a possible infinite

It's ugly because you are forcing the system to parse something that
was already parsed.

Well, to be true to the word, during parsing COPY view TO
the parser never saw SELECT * FROM view.

On the other hand I don't see why you are arguing in favor of a useless
feature whose coding is dubious; you can have _the same thing_ with nice
code and no discussion.

Because of [1] and because Mr. Schoenig's arguments
about changing schemas.

Best regards,
Zoltán Böszörményi

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to