Re: Speed dblink using alternate libpq tuple storage

On Thu, Apr 05, 2012 at 12:49:37PM -0400, Tom Lane wrote:
> Marko Kreen <markokr@gmail.com> writes:
> > Minor cleanups:
> 
> > * Change callback return value to be 'bool': 0 is error.
> >   Currently the accepted return codes are 1 and -1,
> >   which is weird.
> 
> No, I did it that way intentionally, with the thought that we might add
> back return code zero (or other return codes) in the future.  If we go
> with bool then sensible expansion is impossible, or at least ugly.
> (I think it was you that objected to 0/1/2 in the first place, no?)

Well, I was the one who added the 0/1/2 in the first place,
then I noticed that -1/0/1 works better as a triple.

But the early-exit from callback creates unnecessary fragility
so now I'm convinced we don't want to do it that way.

> >   If we happen to have the 'early-exit' logic in the future,
> >   it should not work via callback return code.
> 
> This assumption seems unproven to me, and even if it were,
> it doesn't mean we will never have any other exit codes.

I cannot even imagine why we would want new codes, so it seems
like unnecessary mess in API.

But it's a minor issue, so if you intend to keep it, I won't
push it further.

> > * Support exceptions in multi-statement PQexec() by storing
> >   finished result under PGconn temporarily.  Without doing it,
> >   the result can leak if callback longjmps while processing
> >   next result.
> 
> I'm unconvinced this is a good thing either.

This is less minor issue.  Do we support longjmp() or not?

Why are you convinced that it's not needed?

-- 
marko