Re: Patch for streaming resultsets [Viruschecked] [Viruschecked]

On Fri, 3 Jan 2003 17:23:15 +0100, Kovács Péter wrote:

Hello Péter,

To follow the words from the JDBC API docs:
"A SQL statement is precompiled and stored in a PreparedStatement object.
This object can then be used to efficiently execute this statement multiple times."

This seems to be a bit more than just counting the ? and such. For me,
it sounds a bit more like "make every effort to make it run fast if
used multiple times".
That's one of the main reasons for me to make prepared statements
prepared on the server side.

Patric

>You're right. The JDBC API is far from perfect. But the concept which the
>Postgres JDBC maintainers are putting into practice (implementation) --
>namely that the PreparedStatement type has little/nothing to do with server
>side prepared statements, and its main purpose would be to help insert
>variables into the statement string -- does not (with all due respect to the
>mainters' enthusiasm and constant effort to keep alive the development of
>this interface) seem to be well-founded.
>
>Cheers
>
>Peter
>
>PS:
>I do not seem to be able to post on the list because my company has recently
>changed its employees' e-mail addresses, and I do not know yet how to get
>this mess of a Microsoft Outlook to use my old address.
>
>> -----Original Message-----
>> From: Patric Bechtel [mailto:bechtel(at)ipcon(dot)de]
>> Sent: Friday, January 03, 2003 4:26 PM
>> To: pgsql-jdbc(at)postgresql(dot)org
>> Subject: Re: [JDBC] Patch for streaming resultsets [Viruschecked]
>>
>>
>> On Fri, 3 Jan 2003 16:06:22 +0100, Kovács Péter wrote:
>>
>> Ah... no... :-) not especially lazy coders... all good coders
>> are lazy :-)
>>
>> It would be nice if the JDBC folks did add some kind of "I
>> want to use this
>> query more than once, so please do anything to make it fast
>> for MULTIPLE
>> invokations, not only for this one" property. This would
>> really help a bit
>> making this decision a bit easier.
>> As would do a "I'm expecting kind of REALLY BIG result set within this
>> query, would your please take some extra caution, even if
>> hits performance
>> a bit" property do a LOT of favour for the resultset cursor thingy.
>> But sigh, experts have thought out this API, so we non-experts have to
>> live with it... :-\
>>
>> tia
>>
>> Patric
>>
>>
>> >Patric probably thinks that the purpose of the designers of
>> the JDBC API to
>> >include the PreparedStatement type into the API was to
>> address the need for
>> >(the) "inherent behaviour" and not to spare lazy coders
>> writing a few more
>> >lines of code. :))))
>> >
>> >Peter
>> >
>> >> -----Original Message-----
>> >> From: Dave Cramer [mailto:Dave(at)micro-automation(dot)net]
>> >> Sent: Friday, January 03, 2003 3:30 PM
>> >> To: Patric Bechtel
>> >> Cc: pgsql-jdbc(at)postgresql(dot)org
>> >> Subject: Re: [JDBC] 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>
>> >>
>> >>
>> >> ---------------------------(end of
>> >> broadcast)---------------------------
>> >> TIP 2: you can get off all lists at once with the
>> unregister command
>> >> (send "unregister YourEmailAddressHere" to
>> >> majordomo(at)postgresql(dot)org)
>> >>
>> >
>>
>>
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 5: Have you checked our extensive FAQ?
>>
>> http://www.postgresql.org/users-lounge/docs/faq.html
>>
>