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

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)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