Re: Having a plpgsql function return multiple rows that indicate its progress in a cursor like fashion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
Cc: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Having a plpgsql function return multiple rows that indicate its progress in a cursor like fashion
Date: 2010-02-16 15:45:20
Message-ID: 29326.1266335120@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> writes:
> Cursors simply address the problem of "impedance mismatch" (the use of
> that term in this way probably pre-dates ORM, so please don't tell me
> that that term refers exclusively to an ORM problem within an RDBMS
> context). You don't have to fetch the result set all at once where
> that is impractical. However, the entire result set is available on
> the server from the first fetch.

The above statements are not true as far as the cursor mechanism is
concerned (at least not in Postgres). However, they are true as far as
the result of a plpgsql function returning set is concerned. The
function runs to completion, dumping RETURN NEXT outputs into a
"tuplestore", and then returns the tuplestore as its result.

It is possible to code set-returning functions in a suspend-and-resume
style, but none of the available PLs do that; you have to get down to
the C level.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2010-02-16 16:22:32 Re: relacl parsing method?
Previous Message Bruce Momjian 2010-02-16 15:36:02 Re: [GENERAL] possible bug with inheritance?