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

On Tue, 2002-11-19 at 02:14, Barry Lind wrote:
> 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.

I agree with Barry here.

> 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.

Yes. Optional also gets my vote. The majority of usage that I have is
for queries that return few rows. I'm not interested in the overhead of
cursors being added to each of my queries, but I do like the idea of
being able to explicity ask for the functionality when needed. As such
setFetchSize() sounds like the right way to do it. For those that need
it on all the time, the url parameter sounds like a pretty good way of
doing it.

> 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.

Sounds reasonable to me as long as its clear to the programmer what type
they are using. I definitely don't want to see the noncursor based
resultsets closed, but I can't see a better solution for cursor based
ones...

Tom.
--
Thomas O'Dowd, CEO, Nooper.com - Mobile Services Inc., Tokyo, Japan
i-mode & FOMA consulting, development, testing: http://nooper.co.jp/