Re: streaming result sets: progress
От | Nic Ferrier |
---|---|
Тема | Re: streaming result sets: progress |
Дата | |
Msg-id | 878yzqeglj.fsf@pooh-sticks-bridge.tapsellferrier.co.uk обсуждение исходный текст |
Ответ на | Re: streaming result sets: progress (Barry Lind <blind@xythos.com>) |
Список | 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 по дате отправления: