Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?
От | Bryn Llewellyn |
---|---|
Тема | Re: Is the PL/pgSQL refcursor useful in a modern three-tier app? |
Дата | |
Msg-id | 5637673F-472A-49F6-87EF-DCE57879039B@yugabyte.com обсуждение исходный текст |
Ответ на | Re: Is the PL/pgSQL refcursor useful in a modern three-tier app? (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?
|
Список | pgsql-general |
> adrian.klaver@aklaver.com wrote: > >> bryn@yugabyte.com wrote: >> >>> laurenz.albe@cybertec.at wrote: >>> >>> You seem to think that a client request corresponds to a single database request >> >> …I can’t picture a concrete use case where, not withstanding the "where" restriction that my "select" used, I can't tellhow much of the result set I'll need or where reading result #n1 informs me that I next need to scroll and read result#n2. So I was looking for a convincing example. > > Huh? > > You provided your own example earlier: > > "Of course, it all falls into place now. I can see how I could write a client app in, say, Python to write a humongousreport to a file by fetching manageably-sized chunks, time and again until done with a function like my "g()" here,from a cursor that I'd opened using a function like my "f()"." My “Humongous report via client-side Python” example doesn’t call for me to abandon it part way through. Nor does it callfor me to leap forwards as I discover facts along the way that make me realize that I need immediately to see a far distantfact by scrolling to where it is (and especially by scrolling backwards to what I’ve already seen). It was an exampleof this that I was asking for. The bare ability to do controlled piecewise materialization and fetch is clear.
В списке pgsql-general по дате отправления: