"Daniel Verite" <daniel@manitou-mail.org> writes:
> To clarify the compatibility issue, the attached bash script
> compares pre-patch and post-patch client/server combinations with
> different cases, submitted with different copy variants.
> ...
> Also attaching the tables of results with the patch as it stands.
> "Failed" is when psql reports an error and "Data mismatch"
> is when it succeeds but with copied data differing from what was
> expected.
Thanks for doing that --- that does indeed clarify matters.
Obviously, the cases we need to worry about most are the "Data
mismatch" ones, since those might lead to silent misbehavior.
I modified your script to show me the exact nature of the mismatches.
The results are:
* For case B, unpatched both sides, the "mismatch" is that the copy
stops at the \. line. We should really call this the "old expected
behavior", since it's not impossible that somebody is relying on it.
We're okay with breaking that expectation, but the question is whether
there might be other surprises.
* For case B, unpatched-server+patched-psql, the mismatches are
exactly the same, i.e. the user sees the old behavior. That's OK.
* For case B, patched-server+unpatched-psql, the mismatches are
different: the copy absorbs the \. as a data line and then stops.
So that's surprising and bad, as it's neither the old expected
behavior nor the new intended behavior. However, there are two
things that make me less worried about this than I might be.
First, it's pretty likely that the server will not find "\."
alone on a line to be valid input data for the COPY, so that the
result will be an error not silently wrong data. Second, the case
of patched-server+unpatched-psql is fairly uncommon, and people
know to expect that an old psql might not behave perfectly against
a newer server. The other direction of version mismatch is of far
more concern: people do expect a new psql to work with an old server.
* For case C, patched-server+unpatched-psql, the mismatch for embedded
data is again that the copy absorbs the \. as a data line and then
stops. Again, this isn't great but the mitigating factors are the
same as above.
In all other cases, the results are the same or strictly better than
before. So on the whole I think we are good on the compatibility
front and I'm ready to press ahead with the v5 behavior.
However, I've not looked at Artur's coding suggestions downthread.
Do you want to review that and see if you want to adopt any of
those changes?
regards, tom lane
