"Andrew Snow" [EMAIL PROTECTED] writes:
I believe I can work around this problem using cursors (although I
don't know how well DBD::Pg copes with cursors). However, that
doesn't seem right -- cursors should be needed to fetch a large query
without having it all in memory at once...
On Thu, Aug 31, 2000 at 03:28:14PM +1100, Chris wrote:
Jules Bean wrote:
On Thu, Aug 31, 2000 at 12:22:36AM +1000, Andrew Snow wrote:
I believe I can work around this problem using cursors (although I
don't know how well DBD::Pg copes with cursors). However, that
doesn't
On Thu, Aug 31, 2000 at 09:58:34AM +0100, Jules Bean wrote:
On Thu, Aug 31, 2000 at 03:28:14PM +1100, Chris wrote:
but it is true that this is a flaw in postgres. It has been
discussed on hackers from time to time about implementing a "streaming"
interface. This means that the client
-Original Message-
From: Jules Bean
On Thu, Aug 31, 2000 at 09:58:34AM +0100, Jules Bean wrote:
On Thu, Aug 31, 2000 at 03:28:14PM +1100, Chris wrote:
but it is true that this is a flaw in postgres. It has been
discussed on hackers from time to time about implementing a
I believe I can work around this problem using cursors (although I
don't know how well DBD::Pg copes with cursors). However, that
doesn't seem right -- cursors should be needed to fetch a large query
without having it all in memory at once...
Actually, I think thats why cursors were
On Thu, Aug 31, 2000 at 12:22:36AM +1000, Andrew Snow wrote:
I believe I can work around this problem using cursors (although I
don't know how well DBD::Pg copes with cursors). However, that
doesn't seem right -- cursors should be needed to fetch a large query
without having it all in
