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