On Apr 13, 2004, at 11:04 PM, Tom Lane wrote:
> The facility that
> was specifically designed to support JDBC is the V3-protocol prepare/
> bind/execute message group.
Aha. I see. Looks like this is a somewhat separate / lower level problem
from what I had set out to tackle. I see a note in the JDBC driver as it
chooses to either use cursors or server-side prepare:
// We prefer cursor-based-fetch over server-side-prepare here.
// Eventually a v3 implementation should let us do both at once.
The current driver, if asked to use server-side prepares and
not also cursors then currently does indeed issue the
PREPARE, EXECUTE, and DEALLOCATE commands at the
SQL level.
So, making that path v3-aware could:
1) Allow for both cursor-based fetching and prepared
statements.
2) Allow for late-binding of param-types to a prepared
statement, fixing the now-ignored problem of what if the
Nth reuse of a current JDBC server-planned prepared
statement binds types other than what was passed-in
on the first invocation.
This sort of fix belongs down deep in AbstractJDBC1Statement,
whereas my hack-ish cache would exist at a layer much higher
than this, when I follow Oliver's advice and cache PreparedStatements
at the PooledConnection level.
Thanks for the education, as always!
----
James Robinson
Socialserve.com
