Hello Barry,
Does it mean :
I can use two queries in parallel or not ?
regards
Haris Peco
On Wednesday 05 February 2003 01:28, Barry Lind wrote:
> Haris,
>
> The current code does a "BEGIN; DECLARE...". I intend to change this to
> no longer include the BEGIN and instead only allow the use of cursors
> if the driver is running in non-autocommit mode. Since postgres doesn't
> allow cursors to be used across transactions, a commit should also
> invalidate the result set. The current behavior of including the BEGINs
> will cause warning messages and thus the need for the change. However
> since postgres doesn't yet support nested transactions, there isn't a
> need for the commit/rollback you suggest.
>
>
> thanks,
> --Barry
>
> snpe wrote:
> > Hello Barry,
> > What happen if I call two or more statement with setFetchSize, btw.
> >
> > 1. setFetchSize 10 for query on table a and table b
> > 2. select * from a
> > select 10 rows from a
> > 3. select * from b
> > select 10 rows from b
> > 4. I want rows 11-20 from a, now
> > 5. next 10 rows (11-20) from b
> >
> > etc
> >
> > in step 2 'execute' for query table a call 'BEGIN; DECLARE CURSOR ...'
> > in step 3 'execute' for query table b call again 'BEGIN; ...'
> > Can I do this without nested transaction (savepoint)
> > I think that close in ResultSet or Statement must call 'COMMIT' OR
> > 'ROLLBACK', too
> >
> > Can You set parametar in driver URL (true or false) that use cursor
> > automagic for true ?
> >
> > regards
> > Haris Peco
> >
> > On Tuesday 04 February 2003 16:42, Barry Lind wrote:
> >>Paul,
> >>
> >>A patch was just applied to cvs head to better deal with this. The new
> >>behavior is that by default you get the old behavior, but if you call
> >>setFetchSize() it will turn on using cursors to incrementally fetch the
> >>result.
> >>
> >>thanks,
> >>--Barry
> >>
> >>PS. I haven't yet got a new build for the web site, but should in a few
> >>days, so in the meantime, if you want to try this out, you will need to
> >>build from cvs sources.
> >>
> >>Paul Cullum wrote:
> >>>I'm querying a table that has nearly 3 million records in it and when I
> >>>call executeQuery() I get an a java.lang.OutOfMemoryError message. My
> >>>immediate thought was that it was strange that a safe fetch size wasn't
> >>>used automatically so I then I decided to explicitly the fetch size by
> >>>calling the Connection classes setFetchSize() method. Apparently this
> >>>is not implemented in the pg73jdbc3.jar driver. I am surprised that
> >>>the default fetch size is so great as to cause an OutOfMemoryError. What
> >>>is the proper method for using JDBC to query result sets which are
> >>>potentially large?
> >>>
> >>>Thanks,
> >>>Paul
> >>>
> >>>
> >>>---------------------------(end of broadcast)---------------------------
> >>>TIP 5: Have you checked our extensive FAQ?
> >>>
> >>>http://www.postgresql.org/users-lounge/docs/faq.html
> >>
> >>---------------------------(end of broadcast)---------------------------
> >>TIP 5: Have you checked our extensive FAQ?
> >>
> >>http://www.postgresql.org/users-lounge/docs/faq.html
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org