Re: Protocol 3, Execute, maxrows to return, impact?
От | Tom Lane |
---|---|
Тема | Re: Protocol 3, Execute, maxrows to return, impact? |
Дата | |
Msg-id | 1116.1215699748@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Protocol 3, Execute, maxrows to return, impact? ("Stephen R. van den Berg" <srb@cuci.nl>) |
Ответы |
Re: Protocol 3, Execute, maxrows to return, impact?
Re: Protocol 3, Execute, maxrows to return, impact? |
Список | pgsql-hackers |
"Stephen R. van den Berg" <srb@cuci.nl> writes: > Then, from a client perspective, there is no use at all, because the > client can actually pause reading the results at any time it wants, > when it wants to avoid storing all of the result rows. The network > will perform the cursor/fetch facility for it. [ shrug... ] In principle you could write a client library that would act that way, but I think you'll find that none of the extant ones will hand back an incomplete query result to the application. A possibly more convincing argument is that with that approach, the connection is completely tied up --- you cannot issue additional database commands based on what you just read, nor pull rows from multiple portals in an interleaved fashion. regards, tom lane
В списке pgsql-hackers по дате отправления: