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...)
