On Fri, 23 Jul 2010, Tom Lane wrote:
Kris Jurka <bo...@ejurka.com> writes:
On 7/23/2010 6:40 AM, Tom Lane wrote:
I believe this is a misunderstanding of the protocol spec. The spec is
(intended to say that) we'll continue to accept data after reporting an
error, not that we will silently swallow an incorrect data stream and
not complain about it. Which is what this patch will do.
All this does is make binary mode match text mode.
The fact that text mode eats data after \. is a backwards-compatibility
kluge to match the behavior of pre-7.4 COPY. It could very legitimately
be argued to be a bug in itself. I don't think that we should make
binary mode match it. The main concrete reason why not is that binary
mode has almost no redundancy. It would be really easy for the code
change you suggest to result in data being silently discarded with no
hint of what went wrong.
Binary copy mode already does this (eat data silently after -1 field
count). The patch I sent just made it follow the fe/be protocol while it
does so.
jurka=# create table copytest (a int);
CREATE TABLE
jurka=# insert into copytest values (1);
INSERT 0 1
jurka=# \copy copytest to copydata with binary
jurka=# \! echo garbage >> copydata
jurka=# \copy copytest from copydata with binary
jurka=# select * from copytest;
a
---
1
1
(2 rows)
After some reflection, I think the real issue here is that the JDBC
driver is depending on a behavior not stated in the protocol, which
is the relative timing of FE-to-BE and BE-to-FE messages. Once you've
sent the EOF marker, the only correct follow-on for a spec-compliant
frontend is a CopyEnd message. So the backend is just sending its
response a bit sooner. There's nothing in the protocol spec forbidding
that.
What about CopyFail? The protocol docs say nothing about the message
contents only about the messages themselves.
Kris Jurka
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
