Hans-Juergen Schoenig wrote:
> >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).
> this will definitely be the case - however, this is not what it was made 
> for. it has not been made to be fast but it has been made to fulfill 
> some other task. the reason why this has been implemented is: consider a 
> large scale database containing hundreds of gigs of data. in our special 
> case we have to export in a flexible way. the data which has to be 
> exported comes from multiple tables (between 3 and 7 depending on the 
> data we are looking at in this project. the export has to be performed 
> in a flexible way and it needs certain parameters. defining tmp tables 
> and store the data in there is simply not "nice" at all. in most cases 
> exports want to transform data on the fly - speed is not as important as 
> flexibility here.

My question is, if we allow this:

copy (select * from view) to stdout;

(or to a file, whatever), is it enough for you?  Or would you insist on
also having

copy view to stdout;

We can, and the posted patch does, support the first form, but not the
second.  In fact I deliberately removed support for the second form for
Zoltán's patch because it uglifies the surrounding code.

Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to