Mark Woodward wrote: >> Mark Woodward wrote: ... >>> This runs completely in the background and can serve as a running >>> backup. >> And you are sure it would be much faster then a server local running >> psql just dumping the result of a query? > > No I can't be sure of that at all, but .... The COPY command has a > specific use that is understood and an operation that is separate from the > normal query mechanism.
Unless you change it to actually execute a query ;) >> (And you could more easy avoid raceconditions in contrast to several >> remote clients trying to trigger your above backup ) > > Again, the examples may not have been precise in presenting "why," the > focus was mostly "what" so it could be discussed. As a generic feature it > has many potential uses. Trying to debate and defend a specific use limits > the potential scope of the feature. Thats why I'm asking. I'm still wondering which use-case actually defends the integration of the resultset-formatter into the backend vs. just doing it in the frontend (in both places there are already some routines which could be used to implent). > Why have COPY anyway? Why not just use "SELECT * FROM TABLE?" Because the special SELECT * FROM TABLE can be optimized aparently. Ah yes, and if usual result fetch requires storing result set in server ram, it would be nicer to change that if possible. I think we run SELECT ... much more often then COPY ;-) (And I hope nobody comes up with the idea if copy would be implemented to execute queries, to generally use COPY instead of select for large result sets in applications. Goodbye portability...) ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org