Re: Speed dblink using alternate libpq tuple storage

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Speed dblink using alternate libpq tuple storage
Дата
Msg-id 6357.1333644577@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
Ответы Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: patch: improve SLRU replacement algorithm
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Another review of URI for libpq, v7 submission