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