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
