Hi dim, > Would returning a refcursor then using fetch in the application be > another solution? I assume not, since nobody stepped forward and offered a way, even though I suggested that returning a refcursor may be the way to go (you'll recall that you suggested that to me in IRC - I'm sternocera there. I believe we met in Paris too). As I said, "I guess my question boils down to: can I return a cursor, but not to return the result of a single select, but of multiple different selects in succession, to report progress as described, or, alternatively, do something that will produce similar results?" I also said: "Cursors simply address the problem of "impedance mismatch"...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." Tom contradicted this, but I believe he just meant that my statement was technically inaccurate, and not that it was conceptually inaccurate. My (perhaps incorrect) understanding is that once you open a cursor, you cannot change that which will later be fetched from the same cursor - What rows will be returned when everything is fetched is determined when the cursor is opened. Also, I cannot very well open a cursor twice, because, as the docs say, "the cursor cannot be open already" when opening a cursor. So, unless I'm mistaken, I don't think returning a refcursor helps me here. > 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. I'll investigate. To be perfectly frank, I am probably overextending myself in doing so, because a) I am not familiar with the PostgreSQL codebase and b) Tom's admonition about the likely difficulty of doing this indicates that it is probably quite an involved task. I think it would be useful to articulate, in broad strokes, what this feature should look like, if not for my benefit, then for the benefit of whoever will eventually implement it (because, given the aspirations and momentum of the postgres community, and the obvious utility of what I've described, I think it's inevitable that *someone* will). Regards, Peter Geoghegan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
