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