On 16 Feb 2010, at 12:35, Peter Geoghegan wrote: > As I've already said, the problem with this approach is that I see all > 3 messages at once, when the CONNECTION_EXCEPTION is thrown and we > finally RETURN, after about 7 seconds (which is undoubtedly how > RETURNS TABLE is documented to behave). I want (although, as I've > said, don't expect) to see the first two messages immediately, and > only the third when the connection fails, so I know what's happening > in real-time. 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... I'm running PostgreSQL 8.4.1 on i386-apple-darwin10.0.0, compiled by GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646), 64-bit !DSPAM:737,4b7a925f10448503891907!
Attachment:
ret_next_test.sql
Description: Binary data
Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:737,4b7a925f10448503891907!
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
