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

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Peter Geoghegan <peter.geoghegan86@gmail.com> writes:
>> Aren't my requirements sufficiently common to justify developing a
>> mechanism to report progress back to client applications during batch
>> operations and the like?
>
> Have you experimented with RAISE NOTICE?  Using it this way is a bit of
> a hack maybe, but I think you are entirely unaware of what would be
> involved in producing something that's less of a hack.

Would returning a refcursor then using fetch in the application be
another solution?

As far as hacking is concerned, I think it boils down to materialise
against value-per-call implementation, right? Not saying it's easy to
implement value-per-call support in plpgsql, but should the OP think
about what's involved, is that the track to follow?

  http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/backend/utils/fmgr/README;hb=HEAD#l380
  http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=d9a319525591bc437e4770b4e796a7517844a784

The first link is the fmgr/README explaining the concepts, and the
second one is a recent enough patch dealing with materialise and
value-per-call in the context of SQL functions.

Regards,
--
dim