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 + ? ");
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
In response to
pgsql-jdbc by date
|Next:||From: Kris Jurka||Date: 2005-01-30 06:36:23|
|Subject: Re: Fix for changing parameter types with server prepared|
|Previous:||From: Kris Jurka||Date: 2005-01-28 23:46:28|
|Subject: Re: [SPAM] - Re: JDBC HighLoad - Found word(s) XXX in the|