Re: Re: JDBC 2.0 conformance, documentation and todo list

Поиск
Список
Период
Сортировка
От Rene Pijlman
Тема Re: Re: JDBC 2.0 conformance, documentation and todo list
Дата
Msg-id 2jh4ntodshpar90nq6uqjub8voq4u9q5ac@4ax.com
обсуждение исходный текст
Ответ на Re: JDBC 2.0 conformance, documentation and todo list  (Barry Lind <barry@xythos.com>)
Ответы Re: Re: JDBC 2.0 conformance, documentation and todo list
Список pgsql-jdbc
Hello Barry,

Thanks a lot. I've incorporated your items
on http://lab.applinet.nl/postgresql-jdbc/

I'll also incorporate your postings from last week about bytea,
large objects and such.

Regards,
René Pijlman

On Wed, 08 Aug 2001 20:56:05 -0700, you wrote:
>Rene,
>
>First off, thank you for pulling this information together in one place.
>  It is really appreciated.
>
>I was going through your list of issues and I had the following comments
>to add:
>
>Batch Updates
>   The current implementation is poor.  As you point out the
>implementation of storing up the statements and then executing them one
>by one defeats the purpose of the batch methods.  The intended behaviour
>is to send a set of updates/inserts in one round trip to the database.
>The server does support this functionality (you can send multiple
>statements in one call by using a semicolon as a statement separator).
>The server will then execute them all at once.  The one limitation is
>that the oid/row count returned by such a batch update only reflects the
>oid/row count of the last statement in the batch.  In reading the spec
>this behaviour is in conformance if not ideal.
>
>DatabaseMetaData
>
>getDatabaseProductVersion  -  I get a pass on this test when I run.
>supportsANSI92EntryLevelSQL - Since postgres now does support outer
>joins, I think the answer here should be yes.  I think the general
>feeling is that if there is a deviation from entry level SQL92 it is a bug.
>
>
>PreparedStatement
>
>The bytea type is documented for 7.2.  You can see it in the current
>docs off of the developers corner links.
>
>The driver does implement setBlob the same way as setBinaryStream.  In
>fact it uses setBinaryStream in it's implementation.  I believe that
>setBlob is functionally correct in it's assumptions that the underlying
>type is oid and thus a LargeObject.
>
>General Requirements
>
>ODBC escape processing is minimally handled.  The escapes for date
>format are supported, but not the rest.
>
>
>thanks,
>--Barry

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

Предыдущее
От: "RaviShankar K"
Дата:
Сообщение: How to deal with "oid" field when it contains NULL ?
Следующее
От: "RaviShankar K"
Дата:
Сообщение: Retrieving field of type bigint[]