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