"Daniel Verite" <dan...@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