Thread: about the copy command
I read this http://www.postgresql.org/docs/8.4/static/libpq-copy.html
I want to send the copy command and then send the data directly. the server don't send the PGRES_COPY_IN to the client.
While receive the copy in command, the server already know how to do. so the server begin to receive data directly.
While receive the copy to command, the server already know how to do. so the server begin to send data directly. And the client receive data directly.
So I want to delete the send of PGRES_COPY_IN or PGRES_COPY_OUT.
wait for your answers, thanks.
Yue Wang <dawning126@gmail.com> writes: > I read this http://www.postgresql.org/docs/8.4/static/libpq-copy.html > I want to send the copy command and then send the data directly. the server > don't send the PGRES_COPY_IN to the client. > While receive the copy in command, the server already know how to do. so > the server begin to receive data directly. > While receive the copy to command, the server already know how to do. so > the server begin to send data directly. And the client receive data > directly. > So I want to delete the send of PGRES_COPY_IN or PGRES_COPY_OUT. This argument ignores the possibility that the COPY command will fail at startup, which could happen for example because of a misspelled table name, lack of permissions, etc etc. So I don't think there's going to be a lot of interest in changing the protocol in this way. Also, for the COPY OUT case, there's not any extra round trip involved anyway: the server will start sending data immediately, and I don't think it will even bother to flush the CopyOutResponse message separately. So there's really no gain to be had on that side. For COPY IN, it's true that you'll spend an extra network round trip if you wait for the server ack before you start to send data. But if you're sending so little data that one roundtrip matters, you're probably better off forgetting about COPY and sending a regular INSERT command instead. regards, tom lane