On Apr 13, 2004, at 5:18 PM, Oliver Jowett wrote:
> This sounds like JDBC3's "statement pooling" option. There's no API
> for this, it's just allowable behaviour, so we should be fine to
> implement something like this.
Diving in, I see that Postgres's PREPARE statement needs the types
up-front, as in:
PREPARE t_prep (TEXT) as select id from users where name = $1;
But PreparedStatement doesn't know the JDBC datatypes (which we map onto
Postgres types) until execute time. Hence I guess
delaying of server-preparing until execute-time, when all of the params
been pushed in.
A global cache of prepared PreparedStatements seems to have to assume
subsequent calls ought to be executed with the same param types. Is
bold of an assumption -- I know that in my EJB code this will hold, but
know about others.
Unless the key to the map of cached prepared statement also
type signatures of each param. Ugh. That would push fetching from the
until the actual executeQuery() call on PreparedStatement, as opposed to
at Connection.prepareStatement(String queryPattern) time -- which I
can semi-gracefully hook into in AbstractJdbc3Connection.java to
keep JDBC1/2 unaffected. The executeQuery() hooking looks harder to
implement without poisoning JDBC 1/2.
Unrelated, what is the philosophy regarding putting what type of code in
the AbstractXXX class as opposed to the JDBCNXXX class? I'm sure there's
a good reason, but it escapes my grasp at the moment ...
In response to
pgsql-jdbc by date
|Next:||From: Oliver Jowett||Date: 2004-04-14 02:22:24|
|Subject: Statement pooling implementation (was Re: Under what circumstances
does PreparedStatement use stored plans?)|
|Previous:||From: James Robinson||Date: 2004-04-14 01:02:16|
|Subject: Re: Under what circumstances does PreparedStatement use stored plans?|