Re: streaming result sets: progress
От | Nic Ferrier |
---|---|
Тема | Re: streaming result sets: progress |
Дата | |
Msg-id | 871y5hb02c.fsf@pooh-sticks-bridge.tapsellferrier.co.uk обсуждение исходный текст |
Ответ на | Re: streaming result sets: progress (Scott Lamb <slamb@slamb.org>) |
Список | pgsql-jdbc |
Scott Lamb <slamb@slamb.org> writes: > Nic Ferrier wrote: > > > Thomas O'Dowd writes: > > > > > > >>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... > > > > > > How can we make clear what type of ResultSet is being used? > > I suggest with ResultSet.CLOSE_CURSORS_AT_COMMIT (cursor method) vs > ResultSet.HOLD_CURSORS_OVER_COMMIT (old method). You can both request a > certain type when you create a Statement or PreparedStatement and get > the type of the resultset from the Statement or PreparedStatement. Sounds good. I'll bung that into the latest patch which will be released tommorow (I'll be setting up a website soon /8->) Tommorow's patch will also include code to handle ResultSets coming back from procs (via cursors). This is based on Barry and my conversations from earlier this autumn. Nic
В списке pgsql-jdbc по дате отправления: