8.0 drivers released.

Поиск
Список
Период
Сортировка
От Kris Jurka
Тема 8.0 drivers released.
Дата
Msg-id Pine.BSO.4.56.0501170706010.29112@leary.csoft.net
обсуждение исходный текст
Ответы Re: 8.0 drivers released.
Re: 8.0 drivers released.
Список pgsql-jdbc
With the 8.0 server release coming later this week, I've put up a new set
of JDBC drivers.  I haven't had time to write up a full set of release
notes, so this email will have to suffice for now...

Naturally there are a huge number of minor improvements and fixes,
but these are the big things in 8.0:

- True V3 protocol support.
- Savepoints.
- No more "idle in transaction" problems.
- Binary data doesn't use fifty times the necessary memory.
- SSL connection customization
- driver configuration via properties file
- 5.0 JDK compiles

Major compatibility issues that come to mind immediately.

The driver now always uses some form of server prepared statement.  This
means that all data is now strongly typed instead of mashed together into
a query string for the server to figure out.  If you have an application
that uses setString(x, myString) for every type, you are not going to be
happy.  The driver needs to know what the real column type is in the
database and it infers this from the setXXX call you make.  This presents
some tricky problems when dealing with postgresql datatypes that do not
match up exactly with Java datatypes that are only solved by using a
custom PGobject subclass to pass both the data and the correct type to the
driver.  This also extends to null values, no longer is setObject(x, null)
valid because it does not contain type information for the driver to use.

Previously Statement.executeQuery("INSERT ... ; SELECT currval('myseq')");
would return a ResultSet.  This is no longer true and I don't believe it
was ever strictly legal.  This should be correctly written in separate
queries or:

Statement.execute("INSERT ...; SELECT currval('myseq')");
Statement.getMoreResults();
ResultSet rs = Statement.getResultSet();

Calling PreparedStatement.setBinaryStream now requires a correct length
argument.  Previously Integer.MAX_VALUE or similar could be used and it
would read the stream to completion, but with the ability to stream data
directly to the server and not use up outrageous amounts of memory means
that we need to know the correct length from the outset.

Kris Jurka

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

Предыдущее
От: Kris Jurka
Дата:
Сообщение: Re: Translation update: pt_BR
Следующее
От: Guillaume Cottenceau
Дата:
Сообщение: Re: Problem : Japanese Character Support