Re: Fix for changing parameter types with server prepared statements - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: Fix for changing parameter types with server prepared statements
Date
Msg-id Pine.BSO.4.56.0501300102030.16446@leary.csoft.net
Whole thread Raw
In response to Fix for changing parameter types with server prepared statements (was Re: setObject on PGInterval throws "Unknown Type null")  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: Fix for changing parameter types with server prepared  (Kris Jurka <books@ejurka.com>)
Re: Fix for changing parameter types with server prepared  (Kris Jurka <books@ejurka.com>)
Re: Fix for changing parameter types with server prepared statements  (Oliver Jowett <oliver@opencloud.com>)
Re: Fix for changing parameter types with server prepared statements  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-jdbc

On Fri, 28 Jan 2005, Oliver Jowett wrote:

> I just fixed this in CVS, it wasn't as painful to do as I originally
> thought. It should also work for the NULL-as-oid-0 case if we go back to
> doing that -- any change in parameter type oids causes a reprepare.
>

The attached patch implements the Describe (Statement) protocol
message which allows us to do a number of things.

First it re-enables untyped nulls.  When a statement with an untyped null
is executed (and we expect it to be reused) a describe statement is issued
to get the backend to resolve its type for us which is then fed back into
the ParameterList.  This allows the following code to not require
re-parses for every execution:

PreparedStatement ps = conn.prepareStatemet("SELECT 1 + ? ");
ps.setObject(1, null);
ps.executeQuery();
ps.setInt(1, 1);
ps.executeQuery();
ps.setObject(1, null);
ps.executeQuery();
ps.setInt(1, 1);
ps.executeQuery();

A problem I came across is that it will actually require a reparse on the
second execution above because the prepared statements parameters are
cloned and stored during QueryExecutorImpl.sendParse which is before the
results of the describe statement message can be fed back into the system.
Any ideas on this would be appreciated.

Additionally a new QueryExecutor.QUERY_ flag has been added that indicates
we only want to describe the statement and not actually execute.  This
uses the new Describe(Statement) support to implement
PreparedStatement.getMetaData() for an unexecuted statement and
PreparedStatement.getParameterMetaData().

Kris Jurka

Attachment

pgsql-jdbc by date:

Previous
From: Kris Jurka
Date:
Subject: Re: [SPAM] - Re: JDBC HighLoad - Found word(s) XXX in the
Next
From: Kris Jurka
Date:
Subject: Re: Fix for changing parameter types with server prepared