Re: Under what circumstances does PreparedStatement use stored plans?

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