Re: Speed dblink using alternate libpq tuple storage - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Speed dblink using alternate libpq tuple storage
Date
Msg-id 6357.1333644577@sss.pgh.pa.us
Whole thread Raw
In response to Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
Responses Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
List pgsql-hackers
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?)

>   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


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: patch: improve SLRU replacement algorithm
Next
From: Peter Eisentraut
Date:
Subject: Re: Another review of URI for libpq, v7 submission