On Fri, Apr 26, 2013 at 10:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> However, the documentation in libpq.sgml is a bit bogus too, because it
>>> counsels trying the PQputCopyEnd() call again, which will not work
>>> (since we already changed the asyncStatus). We could make that say "a
>>> zero result is informational, you might want to try PQflush() later".
>>> The trouble with this, though, is that any existing callers that were
>>> coded to the old spec would now be broken.
>
>> Changing the meaning of a 0 return code seems like a bad idea.
>> However, not ever returning 0 isn't great either: someone could be
>> forgiven for writing code that calls PQputCopyData/End() until they
>> get a 0 result, then waits for the socket to become write-OK before
>> continuing.
>
> Anybody who tried that would have already discovered that it doesn't
> work, so that argument seems pretty hollow.
>
> What I'm suggesting is that we fix the documentation to match what
> the code actually does, ie 1 and -1 are the only return codes, but
> in nonblock mode it may not actually have flushed all the data.
> I do not see how that can break any code that works now.
>
> An alternative possibility is to document the zero return case as
> "can't happen now, but defined for possible future expansion", which
> I rather suspect was the thought process last time this was looked at.
> The trouble with that is that, if we ever did try to actually return
> zero, we'd more than likely break some code that should have been
> checking for the case and wasn't.
>
> Anyway, in view of the lack of complaints from the field, I think
> changing the behavior of this code would be much more likely to cause
> problems than fix them.
Sure, I don't think we can change the behavior now; I just think it's
a shame that the documented behavior was never implemented. But at
this point we don't have much choice but to live with it.
By the by, might it be time to start thinking about deprecating
protocol version 2, at least for COPY? It seems that supporting it
requires nontrivial contortions of both the front-end and back-end
code, some of which seem possibly relevant to performance. Obviously
we're not going to do anything to 9.3 at this point, but maybe for the
next release...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company