Re: streaming result sets: progress - Mailing list pgsql-jdbc

From Nic Ferrier
Subject Re: streaming result sets: progress
Date
Msg-id 878yzqeglj.fsf@pooh-sticks-bridge.tapsellferrier.co.uk
Whole thread Raw
In response to Re: streaming result sets: progress  (Barry Lind <blind@xythos.com>)
List pgsql-jdbc
Barry Lind <blind@xythos.com> writes:

> Nic,
>
> Here are my thoughts on this topic.
>
> 1) Since the server doesn't support cursors across transactions, I don't
> think the driver should either.  In fact in jdbc3 the DatabaseMetaData
> object has a supportsResultSetHoldability() method that explicitly lets
> the driver tell the application what is does/doesn't support in this area.
>
> I think running multiple sql statements to mimic this behavior is a very
> bad idea.  Since the select statements will run at different times they
> will return different data (since they will pick up commited changes
> between runs), and if you don't include an order by the results are
> completely unpredictable.  If someone wants this very unpredictable
> behavior they can issue the multiple statements themselves.

And app developers can do that themselves if they want to - it's how
I prefer to deal with large result sets within web apps.


> 2) I think the use of cursors should be optional.  In fact since most
> queries don't need them since most queries return a small number of rows
> , I think the use of cursors needs to be turned on.  I think there
> should be two ways to do this:  the first is by setting the fetchSize()
> and the second would be a jdbc url parameter.

Ok. I can do that.


> 3) I think the transaction characteristics of the current patch are just
> fine and conform to the jdbc specification.  The code should
> automatically close the resultset when a commit occurs.  One thing that
> will be confusing is that noncursor based result sets will work accross
> commits, but cursor based ones won't.  But I think that is
> reasonable.

And when we get non-transactional cursors we'll be cooking on wood
(better than gas).


So you think it's more or less ok? What about the changes to the
execution path?

The reason I haven't done the PGRefResultSet patch yet is that I saw
a way, using my new execution path, to reduce the number of classes
that I need to provide the new facility.

If you (and everyone else who needs to) approve the new execution
path stuff then I can do the PGRefResultSet patch as a patch to my
patch /8->


Nic

pgsql-jdbc by date:

Previous
From: Nic Ferrier
Date:
Subject: Re: streaming result sets: progress
Next
From: Jean-Luc Lachance
Date:
Subject: Re: Create table & serial question