Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I thought these patches should not have been applied without more
>> peer review, and now I'm sure of it. I recommend reverting 'em.
> Can we give the submitter a few days to address the issue?
Sure, we have plenty of time. But I don't think the problem can be
fixed without starting over. He's taken routines that had two possible
return conditions ("Success" and "Hard failure: he's dead, Jim") and
added a third condition ("I didn't do what I was supposed to do, or
perhaps only some of what I was supposed to do, because I was afraid
of blocking"). If dealing with that third condition could be hidden
entirely inside libpq, that'd be OK, but the entire point of this
set of changes is to bounce control back to the application rather
than block. Therefore, what we are looking at is a fundamental change
in the API of existing routines, which is *guaranteed* to break existing
applications. (Worse, it breaks them subtly: the code will compile,
and may even work under light load.)
I think the correct approach is to leave the semantics of the existing
exported routines alone, and add parallel entry points with new
semantics to be used by applications that need to avoid blocking.
That's what we've done for queries, and later for connecting, and it
hasn't broken anything.
regards, tom lane
