18 Commits

Author SHA1 Message Date
Dave Cramer
603c46d8ce changes to accomodate updateable resultset mostly just call setSqlQuery on execute 2002-06-13 14:02:50 +00:00
Barry Lind
8860110a74 Removed error message that was incorectly being issued. This fixes a problem reported a few months ago where a select in a rule was causing an insert statement to return a result set which the code was explicitly prohibiting. 2002-04-02 06:24:10 +00:00
Dave Cramer
39c58b9065 changed Cancel to cancel 2002-03-06 03:07:45 +00:00
Dave Cramer
7776319a7e Implementation for cancelQuery by Grant Finnemore <grantf@guruhut.co.za> 2002-02-26 02:15:55 +00:00
Bruce Momjian
f3148bef9f JDBC indenting, comment cleanups. 2001-11-19 22:33:39 +00:00
Bruce Momjian
d2e27b0674 pgjindent jdbc files. First time jdbc files were formatted. 2001-10-25 06:00:05 +00:00
Bruce Momjian
d99794e613 Attached is a patch for current CVS, consisting of a cvs diff -c
for the changed files and a few new files:
- test/jdbc2/BatchExecuteTest.java
- util/MessageTranslator.java
- jdbc2/PBatchUpdateException.java

As an aside, is this the best way to submit a patch consisting
of both changed and new files? Or is there a smarter cvs command
which gets them all in one patch file?

This patch fixes batch processing in the JDBC driver to be
JDBC-2 compliant. Specifically, the changes introduced by this
patch are:

1) Statement.executeBatch() no longer commits or rolls back a
transaction, as this is not prescribed by the JDBC spec. Its up
to the application to disable autocommit and to commit or
rollback the transaction. Where JDBC talks about "executing the
statements as a unit", it means executing the statements in one
round trip to the backend for better performance, it does not
mean executing the statements in a transaction.

2) Statement.executeBatch() now throws a BatchUpdateException()
as required by the JDBC spec. The significance of this is that
the receiver of the exception gets the updateCounts of the
commands that succeeded before the error occurred. In order for
the messages to be translatable, java.sql.BatchUpdateException
is extended by org.postgresql.jdbc2.PBatchUpdateException() and
the localization code is factored out from
org.postgresql.util.PSQLException to a separate singleton class
org.postgresql.util.MessageTranslator.

3) When there is no batch or there are 0 statements in the batch
when Statement.executeBatch() is called, do not throw an
SQLException, but silently do nothing and return an update count
array of length 0. The JDBC spec says "Throws an SQLException if
the driver does not support batch statements", which is clearly
not the case. See testExecuteEmptyBatch() in
BatchExecuteTest.java for an example. The message
postgresql.stat.batch.empty is removed from the language
specific properties files.

4) When Statement.executeBatch() is performed, reset the
statement's list of batch commands to empty. The JDBC spec isn't
100% clear about this. This behaviour is only documented in the
Java tutorial
(http://java.sun.com/docs/books/tutorial/jdbc/jdbc2dot0/batchupdates.html).
Note that the Oracle JDBC driver also resets the statement's
list in executeBatch(), and this seems the most reasonable
interpretation.

5) A new test case is added to the JDBC test suite which tests
various aspects of batch processing. See the new file
BatchExecuteTest.java.

Regards,
Ren? Pijlman
2001-09-06 03:11:59 +00:00
Bruce Momjian
454f44e8e3 Attached is a patch to remove some redundant code in the JDBC driver.
* Merges identical code from org.postgresql.jdbc[1|2].Statement into
  org.postgresql.Statement.
* Moves escapeSQL() method from Connection to Statement (the only place
  it's used)
* Minor cleanup of the new isolation level stuff.
* Minor cleanup of version string handling.

Anders Bengtsson
2001-08-10 14:42:07 +00:00
Peter Mount
cdbd27cb23 Some more updates...
Fri Feb 17 15:11:00 GMT 2001 peter@retep.org.uk
        - Reduced the object overhead in PreparedStatement by reusing the same
          StringBuffer object throughout. Similarly SimpleDateStamp's are alse
          reused in a thread save manner.
        - Implemented in PreparedStatement: setNull(), setDate/Time/Timestamp
          using Calendar, setBlob(), setCharacterStream()
        - Clob's are now implemented in ResultSet & PreparedStatement!
        - Implemented a lot of DatabaseMetaData & ResultSetMetaData methods.
          We have about 18 unimplemented methods left in JDBC2 at the current
          time.
2001-02-16 16:45:01 +00:00
Peter Mount
3d21bf82c3 Some more including the patch to DatabaseMetaData backed out by Bruce.
Tue Feb 13 16:33:00 GMT 2001 peter@retep.org.uk
        - More TestCases implemented. Refined the test suite api's.
        - Removed need for SimpleDateFormat in ResultSet.getDate() improving
          performance.
        - Rewrote ResultSet.getTime() so that it uses JDK api's better.

Tue Feb 13 10:25:00 GMT 2001 peter@retep.org.uk
        - Added MiscTest to hold reported problems from users.
        - Fixed PGMoney.
        - JBuilder4/JDBCExplorer now works with Money fields. Patched Field &
          ResultSet (lots of methods) for this one. Also changed cash/money to
          return type DOUBLE not DECIMAL. This broke JBuilder as zero scale
          BigDecimal's can't have decimal places!
        - When a Statement is reused, the previous ResultSet is now closed.
        - Removed deprecated call in ResultSet.getTime()

Thu Feb 08 18:53:00 GMT 2001 peter@retep.org.uk
        - Changed a couple of settings in DatabaseMetaData where 7.1 now
          supports those features
        - Implemented the DatabaseMetaData TestCase.

Wed Feb 07 18:06:00 GMT 2001 peter@retep.org.uk
        - Added comment to Connection.isClosed() explaining why we deviate from
          the JDBC2 specification.
        - Fixed bug where the Isolation Level is lost while in autocommit mode.
        - Fixed bug where several calls to getTransactionIsolationLevel()
          returned the first call's result.
2001-02-13 16:39:06 +00:00
Peter Mount
234599e943 Wed Jan 31 08:46:00 GMT 2001 peter@retep.org.uk
- Some minor additions to Statement to make our own extensions more
          portable.
        - Statement.close() will now call ResultSet.close() rather than just
          dissasociating with it.
2001-01-31 09:23:45 +00:00
Peter Mount
8439a83d84 Tue Jan 30 22:24:00 GMT 2001 peter@retep.org.uk
- Fixed bug where Statement.setMaxRows() was a global setting. Now
          limited to just itself.
        - Changed LargeObject.read(byte[],int,int) to return the actual number
          of bytes read (used to be void).
        - LargeObject now supports InputStream's!
        - PreparedStatement.setBinaryStream() now works!
        - ResultSet.getBinaryStream() now returns an InputStream that doesn't
          copy the blob into memory first!
        - Connection.isClosed() now tests to see if the connection is still alive
          rather than if it thinks it's alive.
2001-01-31 08:26:02 +00:00
Peter Mount
be281916f9 Fri Jan 19 08:47:00 GMT 2001 peter@retep.org.uk
- Applied patch submitted by John Schutz <schutz@austin.rr.com> that
          fixed a bug with ANT's SQL functions (not needed for building but nice
          to have fixed).
2001-01-19 08:49:06 +00:00
Peter Mount
8bc9f0016b Thu Jan 18 17:37:00 GMT 2001 peter@retep.org.uk
- Added new error message into errors.properties "postgresql.notsensitive"
          This is used by jdbc2.ResultSet when a method is called that should
          fetch the current value of a row from the database refreshRow() for
          example.
        - These methods no longer throw the not implemented but the new noupdate
          error. This is in preparation for the Updateable ResultSet support
          which will overide these methods by extending the existing class to
          implement that functionality, but needed to show something other than
          notimplemented:
            moveToCurrentRow()
            moveToInsertRow()
            rowDeleted()
            rowInserted()
            all update*() methods, except those that took the column as a String
            as they were already implemented to convert the String to an int.
        - getFetchDirection() and setFetchDirection() now throws
          "postgresql.notimp" as we only support one direction.
          The CursorResultSet will overide this when its implemented.
        - Created a new class under jdbc2 UpdateableResultSet which extends
          ResultSet and overides the relevent update methods.
          This allows us to implement them easily at a later date.
        - In jdbc2.Connection, the following methods are now implemented:
            createStatement(type,concurrency);
            getTypeMap();
            setTypeMap(Map);
        - The JDBC2 type mapping scheme almost complete, just needs SQLInput &
          SQLOutput to be implemented.
        - Removed some Statement methods that somehow appeared in Connection.
        - In jdbc2.Statement()
            getResultSetConcurrency()
            getResultSetType()
            setResultSetConcurrency()
            setResultSetType()
        - Finally removed the old 6.5.x driver.
2001-01-18 17:37:15 +00:00
Bruce Momjian
a4e3943b3f Back out Gunnar R|nning jdbc changes. 2000-10-09 16:48:19 +00:00
Bruce Momjian
5383b5d8ed Okay, I have some new code in place that hopefully should work better. I
couldn't produce a full patch using cvs diff -c this time since I have
created new files and anonymous cvs usage doesn't allow you to
adds. I'm supplying the modified src/interfaces/jdbc as a tarball at :
http://www.candleweb.no/~gunnar/projects/pgsql/postgres-jdbc-2000-10-05.tgz

The new files that should be added are :

? org/postgresql/PGStatement.java
? org/postgresql/ObjectPool.java
? org/postgresql/ObjectPoolFactory.java

There is now a global static pool of free byte arrays and used byte arrays
connected to a statement object. This is the role of the new PGStatement
class. Access to the global free array is synchronized, while we rely on
the PG_Stream synchronization for the used array.

My measurements show that the perfomance boost on this code is not quite as
big as my last shot, but it is still an improvement. Maybe some of the
difference is due to the new synchronization on the global array. I think I
will look into choosing between on a connection level and global level.

I have also started experimented with improving the performance of the
various conversions. The problem here is ofcourse related handle the
various encodings. One thing I found to speed up ResultSet.getInt() a lot
was to do custom conversion on the byte array into int instead of going
through the getString() to do the conversion. But I'm unsure if this is
portable, can we assume that a digit never can be represented by more than
one byte ? It works fine in my iso-latin-8859-1 environment, but what about
other environments ? Maybe we could provide different ResultSet
implementations depending on the encoding used or delegate some methods of
the result set to an "converter class".

Check the org/postgresql/jdbc2/FastResultSet.java in the tarball above to
see the modified getInt() method.

Regards,

        Gunnar
2000-10-08 19:37:56 +00:00
Peter Mount
e3cc370d15 Added org/postgresql/DriverClass.java to the list of files removed by make clean (it's dynamically built)
Fixed Statement, so that the update count is valid when an SQL DELETE operation is done.
While fixing the update count, made it easier to get the OID of the last insert as well. Example is in example/basic.java
2000-06-06 11:06:09 +00:00
Peter Mount
25dadc8514 Another attempt at 7.0 2000-04-17 20:07:56 +00:00