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
|
| Список | 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 по дате отправления: