Re: [patch] libpq one-row-at-a-time API

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: [patch] libpq one-row-at-a-time API
Дата
Msg-id CAHyXU0yz+bmpqiFAiTgtwJa9cm46hthXTM4onXRtt-tPAhTdxg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [patch] libpq one-row-at-a-time API  (Marko Kreen <markokr@gmail.com>)
Ответы Re: [patch] libpq one-row-at-a-time API  (Leon Smith <leon.p.smith@gmail.com>)
Список pgsql-hackers
On Tuesday, July 24, 2012, Marko Kreen <<a href="mailto:markokr@gmail.com">markokr@gmail.com</a>> wrote:<br
/>>On Wed, Jul 25, 2012 at 1:29 AM, Merlin Moncure <<a
href="mailto:mmoncure@gmail.com">mmoncure@gmail.com</a>>wrote:<br /> >> On Tue, Jul 24, 2012 at 4:59 PM, Marko
Kreen<<a href="mailto:markokr@gmail.com">markokr@gmail.com</a>> wrote:<br />>>> So if we give only
PQgetResult()in 9.2, I do not see that we<br />>>> are locked out from any interesting optimizations.<br />
>><br/>>> Well, you are locked out of having PQgetResult reuse the conn's result<br />>> since that
wouldthen introduce potentially breaking changes to user<br />>> code.<br />><br />> You can specify
specialflags to PQsend or have special PQgetResultWeird()<br /> > calls to get PGresults with unusual behavior.
 LikeI did with PQgetRowData().<br />><br />> I see no reason here to reject PQgetResult() that returns normal
PGresult.<br/><br />Yeah -- I agree.  So, given the scheduling, I think we should go with non-PQgetRowData patch and
reserveoptimized path for 9.3.<br /><br />merlin    

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: [patch] libpq one-row-at-a-time API
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #6748: sequence value may be conflict in some cases