Re: [HACKERS] Trouble with COPY IN

On Fri, 23 Jul 2010, Tom Lane wrote:

> Kris Jurka <books@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