Tom Lane <tgl@xxxxxxxxxxxxx> writes: > Peter Geoghegan <peter.geoghegan86@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
