Re: Patch for streaming resultsets

Patric,

Can you clarify why you want the default behaviour to use server
prepared statements?

I use prepared statements just because they are easier, not because of
any inherent behaviour.

Dave

On Thu, 2003-01-02 at 11:33, Patric Bechtel wrote:
> Hello folks,
>
> I've made a patch against the current CVS version of the JDBC driver,
> which, based upon Nick Ferrier's patch (thanks!), which adds
> streaming result sets to the driver.
> I've made some modifications to the build file, too, as in it's
> current version it's not able to build clean for JDBC3. I think
> I fixed that.
> Another thing I added are three properties which can be included
> inside the URL:
>
> defaultFetchSize=<int>
>
> sets the fetch size default to <int>.
>
> forceFetchSize=<boolean>
>
> in case this property is true, the driver ignores all setFetchSize()
> API calls from the application. It can be used to get apps, which
> "know" the postgres driver, work though... :-)
>
> useServerPrepare=<never|always>
>
> This on alters the behaviour of server prepared statements. The
> default behaviour is that PreparedStatement's DO get prepared
> on server side, and normal Statement's do NOT.
> Setting this property to "never" switches server side preparation
> off completely, whereas setting it to always even makes
> normal Statements prepared ones (which can be nice in case of
> ever and ever repeated queries such as queue lookups).
>
> Please note that some parts of the source are commented out
> for now, as I did not find a way to accomplish the declaration
> of a cursor for a prepared statement. As for now, this seems
> to be a feature in upcoming 7.3.2/7.4. But as soon as one of
> these arrive, we just twig out these comments and there we go...
>
> The patch is, as mentioned above, against the most actual CVS
> version. A single file, PGResultSet.java, belongs into the
> org/postgresql directory; it needs to be added to the
> repository.
>
> Again, a big thank you for Nick Ferrier, as he made the first
> version of this; I cleaned it up and tested it quite
> thoroughly, our own app as all of the test cases seem to work
> flawlessly with it. It seems that I've broken not too much... :-)
>
> have fun,
>
> Patric
>
>
>
> ______________________________________________________________________
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
--
Dave Cramer <Dave(at)micro-automation(dot)net>