1
0
mirror of https://github.com/postgres/postgres.git synced 2025-05-08 07:21:33 +03:00

20 Commits

Author SHA1 Message Date
Barry Lind
12a28d12bb patch to add support for callable statements to the jdbc driver. The patch was submitted by Paul Bethe pmbethe@yahoo.com 2002-06-24 06:16:27 +00:00
Barry Lind
b465f5307f The patch does the following:
Allows you to set the loglevel at runtime by adding ?loglevel=X to the connection URL, where 1 = INFO and 2 = DEBUG.
  Automatically turns on logging by calling DriverManager.setPrintWriter(new PrintWriter(System.out)) if one is not already set.
Adds a Driver.info() message that prints out the version number
Adds member variables logDebug and logInfo that can be checked before making logging methods calls
Adds a build number to the version number string.  This build number will need to be manually incremented when we see fit.

----------------------------------------------------------------------
Modified Files:
 	org/postgresql/Connection.java org/postgresql/Driver.java.in
 	org/postgresql/fastpath/Fastpath.java
 	org/postgresql/jdbc1/DatabaseMetaData.java
 	org/postgresql/jdbc2/Connection.java
 	org/postgresql/jdbc2/DatabaseMetaData.java
 	org/postgresql/largeobject/LargeObjectManager.java
 	org/postgresql/util/PSQLException.java
 	org/postgresql/util/Serialize.java
----------------------------------------------------------------------
2002-06-11 02:55:16 +00:00
Barry Lind
ef7d791074 Changed QueryExecutor.java to correctly read responses from the backend.
Fixed NPE when database name was not passed on the jdbc connection URL
Fixed Connection.isClosed() to not hit the DB for every call
2002-03-26 05:52:50 +00:00
Barry Lind
d013dbed75 Applied patch from Ryouichi Matsuda <r-matuda@sra.co.jp> where the jdbc
driver was not properly handling timestamptz datatype when using the
getObject() method on ResultSet.  Fix adds this datatype to the object mappings.
2002-01-15 06:55:13 +00:00
Barry Lind
4bc8c8dd95 This patch fixes a bug reported by Graham Leggett (minfrin@sharp.fm).
The bug was that any insert or update would fail if the returned oid was
larger than a signed int.  Since OIDs are unsigned int's it was
a bug that the code used a java signed int to deal with the values.  The bug
would result in the error message: "Unable to fathom update count".
While fixing the bug, it became apparent that other code made a similar
assumption about OIDs being signed ints.  Therefore some methods that returned
or took OIDs are arguements also needed to be changed.
Since we are so close to the 7.2 release I have added new methods that
return longs and deprecated the old methods returning ints.  Therefore all
old code should still work without requiring a code change to cast from long to int.  Also note that the methods below are PostgreSQL specific extensions to
the JDBC api are are not part of the spec from Sun, thus it is unlikely that
they are used much or at all.

The deprecated methods are:
  ResultSet.getInsertedOID()
  Statement.getInsertedOID()
  Serialize.store()
  Connection.putObject()
and are replaced by:
  ResultSet.getLastOID()
  Statement.getLastOID()
  Serialize.storeObject()
  Connection.storeObject()
All the deprecated methods returned int, while their replacements return long

This patch also fixes two comments in MD5Digest that the author Jeremy Wohl
submitted.

--Barry
2001-11-25 23:26:59 +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
Barry Lind
839b9bc011 This patch fixes a bug introduced in the jdbc bytea support patch.
That patch broke the ability to read data from binary cursors.
--Barry Lind
 Modified Files:
 	pgsql/src/interfaces/jdbc/org/postgresql/Connection.java
 	pgsql/src/interfaces/jdbc/org/postgresql/ResultSet.java
 	pgsql/src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
 	pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/Connection.java
 	pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java
 	pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/Connection.java
 	pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java
 	pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/UpdateableResultSet.java
2001-10-09 20:47:35 +00:00
Bruce Momjian
ec0ad67403 Attached is a patch to add bytea support to JDBC.
This patch does the following:

- Adds binary datatype support (bytea)
- Changes getXXXStream()/setXXXStream() methods to be spec compliant
- Adds ability to revert to old behavior

Details:

Adds support for the binary type bytea.  The ResultSet.getBytes() and
PreparedStatement.setBytes() methods now work against columns of bytea
type.  This is a change in behavior from the previous code which assumed
the column type was OID and thus a LargeObject.  The new behavior is
more complient with the JDBC spec as BLOB/CLOB are to be used for
LargeObjects and the getBytes()/setBytes() methods are for the databases
binary datatype (which is bytea in postgres).

Changes the behavior of the getBinaryStream(), getAsciiStream(),
getCharacterStream(), getUnicodeStream() and their setXXXStream()
counterparts.  These methos now work against either the bytea type
(BinaryStream) or the text types (AsciiStream, CharacterStream,
UnicodeStream).  The previous behavior was that these all assumed the
underlying column was of type OID and thus a LargeObject.  The
spec/javadoc for these methods indicate that they are for LONGVARCHAR
and LONGVARBINARY datatypes, which are distinct from the BLOB/CLOB
datatypes.  Given that the bytea and text types support upto 1G, they
are the LONGVARBINARY and LONGVARCHAR datatypes in postgres.

Added support for turning off the above new functionality.  Given that
the changes above are not backwardly compatible (however they are more
spec complient), I added the ability to revert back to the old behavior.
  The Connection now takes an optional parameter named 'compatible'.  If
the value of '7.1' is passed, the driver reverts to the 7.1 behavior.
If the parameter is not passed or the value '7.2' is passed the behavior
is the new behavior.  The mechanism put in place can be used in the
future when/if similar needs arise to change behavior.  This is
patterned after how Oracle does this (i.e. Oracle has a 'compatible'
parameter that behaves in a similar manner).

Misc fixes.  Cleaned up a few things I encountered along the way.


Note that in testing the patch I needed to ignore whitespace differences
in order to get it to apply cleanly (i.e. patch -l -i byteapatch.diff).
Also this patch introduces a new file
(src/interfaces/jdbc/org/postgresql/util/PGbytea.java).

Barry Lind
2001-09-10 15:07:05 +00:00
Bruce Momjian
e30b283f30 Attached is my attempt to clean up the horrors of the ExecSQL() method in
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
2001-09-06 03:13:34 +00:00
Bruce Momjian
76a6da8a1b Attached is a patch to fix the current issues with building under jdbc1.
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
2001-08-24 16:50:18 +00:00
Bruce Momjian
509f5d241a This patch merges the identical methods from the JDBC1 and JDBC2
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
2001-07-30 14:51:19 +00:00
Bruce Momjian
eec08cddb4 Great, here is a context diff of CVS for implementing the get/setCatalog methods
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
2001-07-21 18:56:17 +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
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
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