Re: Fix for changing parameter types with server prepared statements

Поиск
Список
Период
Сортировка

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

Вложения

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Kris Jurka
Дата:
Сообщение: Re: [SPAM] - Re: JDBC HighLoad - Found word(s) XXX in the
Следующее
От: Kris Jurka
Дата:
Сообщение: Re: Fix for changing parameter types with server prepared