Re: libpq COPY handling - Mailing list pgsql-hackers
From | Gavin Flower |
---|---|
Subject | Re: libpq COPY handling |
Date | |
Msg-id | 517ADF07.8010206@archidevsys.co.nz Whole thread Raw |
In response to | Re: libpq COPY handling (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
<div class="moz-cite-prefix">On 27/04/13 02:48, Tom Lane wrote:<br /></div><blockquote cite="mid:11420.1366987729@sss.pgh.pa.us"type="cite"><pre wrap="">Robert Haas <a class="moz-txt-link-rfc2396E" href="mailto:robertmhaas@gmail.com"><robertmhaas@gmail.com></a>writes: </pre><blockquote type="cite"><pre wrap="">On Thu, Apr 25, 2013 at 1:56 PM, Tom Lane <a class="moz-txt-link-rfc2396E" href="mailto:tgl@sss.pgh.pa.us"><tgl@sss.pgh.pa.us></a>wrote: </pre><blockquote type="cite"><pre wrap="">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. </pre></blockquote></blockquote><pre wrap=""> </pre><blockquote type="cite"><pre wrap="">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. </pre></blockquote><pre wrap=""> 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. regards, tom lane </pre></blockquote><font size="-1">The original usage of returns codes was a<font size="-1">s</font> an offset for the OperatingSystem to jump to in a list of addresses to execute, after program co<font size="-1">mp<font size="-1">letion.</font></font></font> Zero offset was to the first address for normal completion, then 4 for the next address... Addresses were stored in 4 bytes. Hence an historical tendency to define return codes in multiple of 4. Thisdates back to the Mainframe days, pre UNIX, even!<br /><br /> Personally I would prefer zero to indicate an error, onthe basis that is the default value for memory, but historical usage makes that impractical! So we are stuck with zerobeing interpreted as the return code indicating 'Normal' completion - bash, and other Linux shells, are designed on thisassumption.<br /><br /> I first came across this return code convention when I was programming Mainframes in the early1970's.<br /><br /><br /> Cheers,<br /> Gavin<br />
pgsql-hackers by date: