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
