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 по дате отправления: