Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Bryn Llewellyn <bryn(at)yugabyte(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?
Date: 2023-03-15 07:28:48
Message-ID: f649cf03d1e25e8c7778ce75a25b98818c0ffd9c.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 2023-03-14 at 17:50 -0700, Bryn Llewellyn wrote:
> Section "43.7. Cursors” in the PL/pgSQL chapter of the doc
> (www.postgresql.org/docs/current/plpgsql-cursors.html#PLPGSQL-CURSOR-DECLARATIONS) starts with this:
>
> «
> [...]
> A more interesting usage is to return a reference to a cursor that a function has created,
> allowing the caller to read the rows. This provides an efficient way to return large row
> sets from functions.
> »
>
> I can't convince myself that this division of labor is useful. And especially I can't convince
> myself that the "pipeling" capability is relevant in a three-tier app with a stateless browser UI.

You seem to think that a client request corresponds to a single database request, but that
doesn't have to be the case. Satisfying a client request can mean iterating through a result set.

Cursors shine wherever you need procedural processing of query results, or where you don't
need the complete result set, but cannot tell in advance how much you will need, or where
you need to scroll and move forward and backward through a result set.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tim.Colles 2023-03-15 09:02:17 odd (maybe) procedure cacheing behaviour
Previous Message Adrian Klaver 2023-03-15 04:30:28 Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?