Re: streaming result sets: progress

From: Nic Ferrier <nferrier(at)tapsellferrier(dot)co(dot)uk>
To: Barry Lind <blind(at)xythos(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: streaming result sets: progress
Date: 2002-11-18 21:02:48
Message-ID: 878yzqeglj.fsf@pooh-sticks-bridge.tapsellferrier.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Barry Lind <blind(at)xythos(dot)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

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Jean-Luc Lachance 2002-11-18 21:06:53 Re: Create table & serial question
Previous Message Nic Ferrier 2002-11-18 20:58:52 Re: streaming result sets: progress