On Tue, 2003-03-18 at 19:00, Hiroshi Inoue wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The question here is do we want to offer a half-baked solution,
recognizing that it's some improvement over no solution at all?
Or do we feel it
On Wednesday 19 March 2003 04:33 am, you wrote:
Dave Cramer [EMAIL PROTECTED] writes:
On Tue, 2003-03-18 at 19:00, Hiroshi Inoue wrote:
ODBC(maybe JDBC also) has cross-transaction result sets
(rather than cursors) since long by simply holding all
results for a query at client side.
Neil Conway writes:
I'm currently planning to implement (1), as it is sufficient for the
immediate need that I'm facing.
What need are you facing, and why is it not sufficient to explicitly store
the query results in a temporary table?
--
Peter Eisentraut [EMAIL PROTECTED]
On Tue, 2003-03-18 at 19:00, Hiroshi Inoue wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The question here is do we want to offer a half-baked solution,
recognizing that it's some improvement over no solution at all?
Or do we feel it
Folks,
I'm currently working on an implementation of cursors that can function
outside the transaction that created them (the SQL spec calls them
holdable cursors). I can see 2 main ways to implement this:
(1) During the transaction that created the holdable cursor, don't do
anything special.
On Mon, 2003-03-17 at 22:01, Alvaro Herrera wrote:
What about opening a pseudo-transaction that exists only to serve the
cursor?
What exactly do you mean by a pseudo-transaction?
Keep in mind we don't have nested transactions (yet?), and that the
holdable cursor needs to be accessible both
Bruce Momjian [EMAIL PROTECTED] writes:
Why don't you like (1)? It seems fine to me, and I don't see how we are
magically going to do any better in the future.
The restrictions of (1) seem pretty obvious to me ... but I don't
see any prospect of doing better in the near future, either.
I think (1) is fine. When I used Informix, we did lots of huge cursors
that we pulled from for reports, and they consumed huge amounts of RAM
before we could do a fetch --- and we expected that. It doesn't seem
worth adding complexity to avoid that, especially since even if (2) was
done, there
