Re: Scrolling through cursors

For my information; this means I probably need a
new connection object for each cursor due to the fact
that it is within a transaction and those are serial in
nature by default on a connection even though this
is a pure select statement. This begs the question
of how expensive is a new connection. Is it a new
thread or process on the backend? I think the answer
is process. Again FMI, why is a cursor necessarily
within a transaction? Also I think any connection
object is serialized at the backend anyway true/false?

TIA for any responses.

BTW, this is not a complaint by me as most modern UNIX'es
are reasonably efficient at process creation and destruction
especially when the initial data and stack segments are
reasonable in size since the Text segment is irrelevant.
Might be more of a problem for other OS'es.

At 10:48 PM 3/17/2002 -0500, Dave Cramer wrote:
>Fredik
>
>Here is some code which uses cursors
>
>Dave
>
>   public void testCursor()
>   {
>     Connection con = null;
>     try {
>       con = getConnection();
>
>       // cursors work inside a transaction
>       con.setAutoCommit(false);
>
>       Statement stmt = con.createStatement();
>
>       // sufficiently long select as to get us something we can scroll
>through
>       stmt.execute("declare cursorname cursor for select * from
>pg_class");
>
>       ResultSet rs = stmt.executeQuery("fetch 10 from cursorname");
>
>       while (rs.next()){
>         System.out.println(rs.getString(1));
>       }
>       rs.close();
>
>       // close the cursor
>       con.commit();
>
>     }
>     catch (Exception ex)
>     {
>       ex.printStackTrace();
>     }
>     finally
>     {
>       try {
>         if ( con != null )
>           con.close();
>       }catch ( SQLException ex ) {}
>     }
>
>   }
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org