the JDBC driver.

I've done this by extracting it into a new method object called
QueryExecutor (should go into org/postgresql/core/) and then taking it
apart into different methods in that class.

A short summary:

* Extracted ExecSQL() from Connection into a method object called
  QueryExecutor.

* Moved ReceiveFields() from Connection to QueryExecutor.

* Extracted parts of the original ExecSQL() method body into smaller
  methods on QueryExecutor.

* Bug fix: The instance variable "pid" in Connection was used in two
  places with different meaning. Both were probably in dead code, but it's
  fixed anyway.

Anders Bengtsson

  This patch moves the logic that looks up TypeOid, PGTypeName, and
SQLTypeName from Field to Connection.  It is moved to connection since
it needs to differ from the jdbc1 to jdbc2 versions and Connection
already has different subclasses for the two driver versions.  It also
made sense to move the logic to Connection as some of the logic was
already there anyway.

Barry Lind

* 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

Here is a context diff from latest cvs

And I see why you couldn't apply the last diff, the setCatalog diff has
been backed out, that was causing the compile problem in the first
place.

This following one needs to be applied to allow the current cvs to
compile

Dave Cramer

1) improves performance of commit/rollback by reducing number of round
trips to the server
2) uses 7.1 functionality for setting the transaction isolation level
3) backs out a patch from 11 days ago because that code failed to
compile under jdk1.1

Details:

1)  The old code was doing the following for each commit:
   commit
   begin
   set transaction isolation level xxx
thus a call to commit was performing three round trips to the database.
  The new code does this in one round trip as:
   commit; begin; set transaction isolation level xxx

In a simple test program that performs 1000 transactions (where each
transaction does one simple select inside that transaction) has the
following before and after timings:

Client and Server on same machine

old         new
---         ---
1.877sec    1.405sec   25.1% improvement

Client and Server on different machines
old         new
---         ---
4.184sec    2.927sec   34.3% improvement

(all timings are an average of four different runs)


2)  The driver was using 'set transaction isolation level xxx' at the
begining of each transaction, instead of using the new 7.1 syntax of
'set session characteristics as transaction isolation level xxx' which
only needs to be done once instead of for each transaction.  This is
done conditionally (i.e. if server is 7.0 or older do the old behaviour,
else do the new behaviour) to not break backward compatibility.  This
also required the movement of some code to check/test database version
numbers from the DatabaseMetaData object to the Connection object.

3) Finally while testing, I discovered that the code that was checked in
  11 days ago actually didn't compile.  The code in the patch for
Connection.setCatalog() used Properties.setProperty() which only exists
in JDK1.2 or higher.  Thus compiling the JDBC1 driver failed as this
method doesn't exist.  Thus I backed out that patch.


Barry Lind

connection implementations (org.postgresql.jdbc[1|2].Connection) into
their superclass (org.postgresql.Connection).

It also changes the close() methods of Connection and PG_Stream, so that
PG_Stream no longer is responsible for sending the termination packet 'X'
to the backend. I figured that protocol-level stuff like that belonged in
Connection more than in PG_Stream.

Anders Bengtsson

 in Connection - note: I've updated setCatalog(String catalog) from my previous
diff so it checks whether it is already connected to the specified catalog.

Jason Davies

Here's a patch against the current CVS. The changes from the previous
patch are mostly related to the changed interface for PG_Stream.

Anders Bengtsson

null terminated strings.  The FE/BE protocol sends in some cases null
terminated strings to the client.  The docs for the FE/BE protocol state
that there is no limit on the size of a null terminated string sent to
the client and a client should be coded using an expanding buffer to
deal with large strings.  The old code did not do this and gave an error
if a null terminated string was greater than either 4 or 8K.  It appears
that with the advent of TOAST very long SQL statements are becoming more
common, and apparently some error messages from the backend include the
SQL statement thus easily exceeding the 8K limit in the old code.

In fixing I also cleaned up some calls in the JDBC fastpath code that
were not doing character set conversion under multibyte, and removed
some methods that were no longer needed.  I also removed a potential
threading problem with a shared variable that was being used in
Connection.java.

Thanks to Steve Wampler for discovering the problem and sending the
initial diffs that were the basis of this patch.

thanks,
--Barry

Marko Kreen

non-multibyte database loosing 8bit characters.  This patch will cause
the jdbc driver to ignore the encoding reported by the database when
multibyte isn't enabled and use the JVM default in that case.

Barry Lind

jdbc/Connection.java

Andy
P.S. in Connection.java if encoding=="WIN" then dbEncoding is set to
"Cp1252".
What if it's Cyrillic "WIN"? Than it should be "Cp1251". Is there any
way to fix that without making different "WIN" encodings in
PostgreSQL?

Andy Rysin

        - 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.

        - 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.

        - These methods in org.postgresql.jdbc2.ResultSet are now implemented:
            getBigDecimal(int) ie: without a scale (why did this get missed?)
            getBlob(int)
            getCharacterStream(int)
            getConcurrency()
            getDate(int,Calendar)
            getFetchDirection()
            getFetchSize()
            getTime(int,Calendar)
            getTimestamp(int,Calendar)
            getType()
          NB: Where int represents the column name, the associated version
              taking a String were already implemented by calling the int
              version.
        - 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:
            cancelRowUpdates()
            deleteRow()
        - Added new error message into errors.properties "postgresql.noupdate"
          This is used by jdbc2.ResultSet when an update method is called and
          the ResultSet is not updateable. A new method notUpdateable() has been
          added to that class to throw this exception, keeping the binary size
          down.
        - Added new error message into errors.properties "postgresql.psqlnotimp"
          This is used instead of unimplemented when it's a feature in the
          backend that is preventing this method from being implemented.
        - Removed getKeysetSize() as its not part of the ResultSet API

Thu Jan 18 09:46:00 GMT 2001 peter@retep.org.uk
        - Applied modified patch from Richard Bullington-McGuire
          <rbulling@microstate.com>. I had to modify it as some of the code
          patched now exists in different classes, and some of it actually
          patched obsolete code.

Wed Jan 17 10:19:00 GMT 2001 peter@retep.org.uk
        - Updated Implementation to include both ANT & JBuilder
        - Updated README to reflect the changes since 7.0
	- Created jdbc.jpr file which allows JBuilder to be used to edit the
          source. JBuilder _CAN_NOT_ be used to compile. You must use ANT for
          that. It's only to allow JBuilders syntax checking to improve the
          drivers source. Refer to Implementation for more details

added to support character set encodings.  However I noticed that the
encoding that is used isn't obtained from the DB.  Since Java uses
unicode UCS2 internally the character set encoding is used to translate
strings from/to the DB encoding.  So it seems logical that the code
would get the encoding from the DB instead of the current method of
requiring the user pass it as a parameter.

Attached is a patch that gets the DB encoding from the DB in the same
manner as is done in libpq/fe-connect.c.  The patch is created off of
the latest CVS sources (Connection.java version 1.10).

Barry Lind

the versioning works. There's also a new utils directory used by Makefile

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

ALTER TABLE <tablename> OWNER TO <username>

Only a superuser may execute the command.

--
Mark Hollomon
mhh@mindspring.com

driver to be set, and a description of said patch.  Please refer to
the latter for more information.

William
--
William Webber                               william@peopleweb.net.au

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

to version 2, and fixes ResultSetMetaData.getColumnDisplaySize().

commit to CVS.

file containing the latest version of the JDBC driver, allowing it to be
compiled and used under JDK 1.2 and later.

NB: None (well almost none) of the new methods actually do anything. This
release only handles getting it to compile and run. Now this is done, I'll
start working on implementing the new stuff.

Now this tar file replaces everything under src/interfaces/jdbc. I had to
do it this way, rather than diffs, because most of the classes under the
postgresql subdirectory have moved to a new directory under that one, to
enable the support of the two JDBC standards.

Here's a list of files in the tar file. Any file not listed here (in the
postgresql directory) will have to be deleted, otherwise it could cause
the driver to fail:

Peter Mount

important step towards making the driver compliant, and means that for
some Java applications and servlets, only a single database connection
is
needed, so in a sence this is a nice little show stopper for 6.4 (and
should still be backward compatible to 6.3.2).

Peter

From: Peter T Mount <patches@maidast.demon.co.uk>

Bug fixes:

        PreparedStatement.setObject didn't handle short's

        ResultSet.getDate() now handles null dates (returns null rather
        than a NullPointerException)

        ResultSetMetaData.getPrecision() now returns 0 for VARCHAR

New features:

        Field now caches the typename->oid in a Hashtable to speed things
        up. It removes the need for some unnecessary queries to the
        backend.

        PreparedStatement.toString() now returns the sql statement that
        it will send to the backend. Before it did nothing.

        DatabaseMetaData.getTypeInfo() now does something.

This fixes a problem in ResultSet.getDate() when the column is NULL
(reported by Vincent Partington <Vincent.Partington@nmg.nl>)

And fixes a problem with Field's (ResultSet.getObject() was proving to be
slow as it repetedly send queries for oid -> name mapping - fixed by
creating a cache. (reported by Mario Ellebrecht <ellebrec@nads.de>)

From: AA van Raalte <alvin@camberlo.demon.co.uk>

This patch fixes the following:

* Fixes minor bug found in DatabaseMetaData.getTables() where it doesn't
  handle default table types.
* It now reports an error if the client opens a database using
  properties, and either the user or password properties are missing. This
  should make the recent problem with Servlets easier to find.
* Commented out obsolete property in Driver.getPropertyInfo()