Re: [HACKERS] Trouble with COPY IN

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.

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.

I would be willing to accept a patch that avoided sending CopyEnd
immediately after receiving EOF, so long as it still threw an error
for extra data; but this is not that patch. The larger issue though
is whether it wouldn't be better to change the driver behavior instead.
I can't help thinking that the JDBC driver must be being overly cute
if this breaks it ... and you're never going to get everybody to
upgrade their server version, even if we were willing to back-patch
the change.

regards, tom lane