Re: [HACKERS] Trouble with COPY IN

On Fri, 23 Jul 2010, Tom Lane wrote:

> Kris Jurka <books(at)ejurka(dot)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