From: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
---|---|
To: | Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> |
Cc: | PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Having a plpgsql function return multiple rows that indicate its progress in a cursor like fashion |
Date: | 2010-02-16 13:09:20 |
Message-ID: | db471ace1002160509p783a893ev1cf17c51e7985a95@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> It seems you're right, I built a simple test-case (see attachment) using timeofday(). The numbers from fetching from a cursor over the set-returning function run away from the selects that directly call timeofday() in between.
> In my case I pause the _client_ between calls, but the results are the same.
> Peculiar...
>
Cursors simply address the problem of "impedance mismatch" (the use of
that term in this way probably pre-dates ORM, so please don't tell me
that that term refers exclusively to an ORM problem within an RDBMS
context). 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.
What I want to do is to fetch the beginning of the result set before
the end has even been determined, with the fetching potentially
blocking in my app to let the plpgsql function catch up and generate a
row that didn't even exist on the server before, and for a time after
the most recent fetch. That is fundamentally different to how cursors
are typically used, and I hope that there is a way to do it.
Thanks,
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-02-16 13:31:07 | Re: Week numbers and calculating weekly statistics/diagrams |
Previous Message | Martijn van Oosterhout | 2010-02-16 12:47:58 | Re: Week numbers and calculating weekly statistics/diagrams |