On Tue, Apr 20, 2010 a= t 11:32 AM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Dave Crooke <dcro= oke@gmail.com> wrote:

> AFAICT from the Java end, ResultSet.close() is= supposed to be
> final.

For that ResultSet. =C2=A0That doesn't mean a ResultSet defines a= cursor.
Such methods as setCursorName, setFetchSize, and setFetchDirection
are associated with a Statement. =C2=A0Think of the ResultSet as the
result of a cursor *scan* generated by opening the cursor defined by
the Statement.

http://java.sun.com/javase/6/docs/api/java/sql= /ResultSet.html#close%28%29

Notice that the ResultSet is automatically closed if the Statement
that generated it is re-executed. =C2=A0That is very much consistent with Statement as the equivalent of a cursor, and not very consistent
with a ResultSet as the equivalent of a cursor.

True, but mechanically there is no other choice - the ResultSet= is created by Statement.executeQuery() and by then it's already in mot= ion .... in the case of Postgres with default settings, the JVM blows out b= efore that call returns.

I am not explicitly creating any cursors, all I'm doing is running = a query with a very large ResultSet.
=C2=A0

Again, you're talking about the *results* from *opening* the cursor.

> At a pragmatic level, the PGSQL JDBC driver has a lot of odd
> behaviours which, while they may or may not be in strict
> compliance with the letter of the standard, are very different
> from any other mainstream database that I have accessed from Java
> .... what I'd consider as normative behaviour, using regular JDBC<= br> > calls without the need to jump through all these weird hoops, is
> exhibited by all of the following: Oracle, SQL Server, DB2, MySQL,
> Apache Derby and JET (MS-Access file-based back end, the .mdb
> format)

Are you talking about treating the Statement object as representing a cursor and the ResultSet representing the results from opening
the cursor, or are you thinking of something else here?

Specific examples:

a. the fact that Statement.ex= ecuteQuery("select * from huge_table") works out of the box with = every one of those databases, but results in java.langOutOfMemory with PG w= ithout special setup. Again, this is to the letter of the standard, it'= s just not very user friendly.

b. The fact that with enterprise grade commercital databases, you can m= ix reads and writes on the same Connection, whereas with PG Connection.comm= it() kills open cursors.

The fact that I've been using JDBC for = 12 years with half a dozen database products, in blissful ignorance of thes= e fine distinctions in the standard until I had to deal with them with PG, = is kinda what my point is :-)

I understand the reasons for some of these limitations, but by no means= all of them.
=C2=A0