Re: streaming result sets: progress

From: Nic Ferrier <nferrier(at)tapsellferrier(dot)co(dot)uk>
To: Scott Lamb <slamb(at)slamb(dot)org>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: streaming result sets: progress
Date: 2002-11-19 23:40:27
Message-ID: 871y5hb02c.fsf@pooh-sticks-bridge.tapsellferrier.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Scott Lamb <slamb(at)slamb(dot)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

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Stuart Robinson 2002-11-19 23:44:11 Re: default values
Previous Message Scott Lamb 2002-11-19 23:05:29 Re: streaming result sets: progress