Re: Speed dblink using alternate libpq tuple storage

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?)

> 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.

> * 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.

regards, tom lane