Re: Cursornames

Do you still want me to write a test case for the bug I found before Kim sent his patch? I can write it today...
Anyway, I know in the spec setFetchSize() is just a hint for the driver, but the current pgsql's driver behavior isn't to create a cursor? I'm pretty sure the query that generated my error was very simple select clause. I don't use DECLARE or multiple queries anywhere in the app.
Btw: the idea of using cursors isn't to prevent the backend from loading all the query results into memory?

On Tue, 05 Aug 2003 11:13:18 -0400
Fernando Nasser <fnasser(at)redhat(dot)com> wrote:

> I looked a little bit more closely into this matter and Kim's patch
> seems correct to me. We do need better comments or to refactor the code
> to make this logic clearer.
>
> What _I think_ happens is that we attempt to create a cursor for
> implementing the fetch size but sometimes this is not possible. For
> instance, the query is itself creating a cursor (a DECLARE statement) or
> there are multiple queries (statements separated by ';').
>
> As setFetchSize() is just a hint for the driver (it does not _need_ to
> consider it), the driver uses the original statement and fetches the
> whole lot (the complete result set). In this case the statement name is
> null.
>
> I would just move the test to right after the test to fetchsize and
> explain the situation in a comment.
>
> Regards to all,
> Fernando
>
> P.S.: Which means that we indeed should not generate an exception if we
> cannot create the cursor as I originally thought.
>
>
>
> Kim Ho wrote:
> > This fixes the behaviour that Felipe Schnack noticed.
> >
> > The logic goes, if the statement name is null (which happens when you do
> > not use cursors or server prepared statements), then we have already
> > fetched all the rows, and there are no more.
> >
> > Cheers,
> >
> > Kim
> >
> >
> > ------------------------------------------------------------------------
> >
> > Index: org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
> > ===================================================================
> > RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java,v
> > retrieving revision 1.13
> > diff -c -p -r1.13 AbstractJdbc1ResultSet.java
> > *** org/postgresql/jdbc1/AbstractJdbc1ResultSet.java 30 Jun 2003 21:10:55 -0000 1.13
> > --- org/postgresql/jdbc1/AbstractJdbc1ResultSet.java 4 Aug 2003 21:32:11 -0000
> > *************** public abstract class AbstractJdbc1Resul
> > *** 131,136 ****
> > --- 131,138 ----
> > String[] binds = new String[0];
> > // Is this the correct query???
> > String cursorName = statement.getStatementName();
> > + if (cursorName == null)
> > + return false;
> > sql[0] = "FETCH FORWARD " + fetchSize + " FROM " + cursorName;
> > QueryExecutor.execute(sql,
> > binds,
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> > message can get through to the mailing list cleanly
>
>
> --
> Fernando Nasser
> Red Hat Canada Ltd. E-Mail: fnasser(at)redhat(dot)com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario M4P 2C9
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

--

/~\ The ASCII Felipe Schnack (felipes(at)ritterdosreis(dot)br)
\ / Ribbon Campaign Analista de Sistemas
X Against HTML Cel.: 51-91287530
/ \ Email! Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter(at)ritterdosreis(dot)br
Fone: 51-32303341