Re: Speed dblink using alternate libpq tuple storage

On Thu, Apr 05, 2012 at 12:49:37PM -0400, Tom Lane wrote:
> Marko Kreen <markokr(at)gmail(dot)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