1. 25 Oct, 2001 1 commit
  2. 10 Sep, 2001 1 commit
    • Bruce Momjian's avatar
      Attached is a patch to add bytea support to JDBC. · ec0ad674
      Bruce Momjian authored
      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
      ec0ad674
  3. 26 Aug, 2001 1 commit
    • Bruce Momjian's avatar
      The attached file: SerializePatch2.tgz, contains a patch for · f4786925
      Bruce Momjian authored
      org.postgresql.util.Serialize and org.postgresql.jdbc2.PreparedStatement
      that  fixes the ability to "serialize" a simple java class into a
      postgres table.
      
      The current cvs seems completely broken in this support, so the patch
      puts it  into working condition, granted that there are many limitations
      with  serializing java classes into Postgres.
      
      The code to do serialize appears to have been in the driver since
      Postgres  6.4, according to some comments in the source.  My code is not
      adding any  totally new ability to the driver, rather just fixing what
      is there so that  it actually is usable.  I do not think that it should
      affect any existing  functions of the driver that people regularly
      depend on.
      
      The code is activated if you use jdbc2.PreparedStatement and try to
      setObject  some java class type that is unrecognized, like not String or
      not some other  primitive type.  This will cause a sequence of function
      calls that results in  an instance of Serialize being instantiated for
      the class type passed.  The  Serialize constructor will query pg_class
      to see if it can find an existing  table that matches the name of the
      java class. If found, it will continue and  try to use the table to
      store the object, otherwise an SQL exception is  thrown and no harm is
      done.  Serialize.create() has to be used to setup the  table for a java
      class before anything can really happen with this code other  than an
      SQLException (unless by some freak chance a table exists that it  thinks
      it can use).
      
      I saw a difference in Serialize.java between 7.1.3 and 7.2devel that I
      didn't  notice before, so I had to redo my changes from the 7.2devel
      version (why I  had to resend this patch now).  I was missing the
      fixString stuff, which is  nice and is imporant to ensure the inserts
      will not fail due to embedded  single quote or unescaped backslashes. I
      changed that fixString function in  Serialize just a little since there
      is no need to muddle with escaping  newlines: only escaping single quote
      and literal backslashes is needed.  Postgres appears to insert newlines
      within strings without trouble.
      f4786925
  4. 21 Aug, 2001 1 commit
    • Bruce Momjian's avatar
      Here's a resend of the patch.gz. I gunzip'ed it fine here · e8f7bfc0
      Bruce Momjian authored
      so it may be a transit problem.  Also removed the 'txt' suffix
      in case that was confusing some transport layer trying to be
      too inteligent for our own good.
      
      This may have been because the Array.java class from the
      previous patch didn't seem to have made it into the snapshot
      build for some reason.  This patch should at least fix that issue.
      
      Greg Zoller
      e8f7bfc0
  5. 12 Jul, 2001 1 commit
  6. 04 Jul, 2001 1 commit
  7. 29 Jun, 2001 1 commit
  8. 25 Jun, 2001 1 commit
    • Bruce Momjian's avatar
      High memory usage · 54361b42
      Bruce Momjian authored
      Here is a patch which inspired by Michael Stephens that should work
      
      Dave Cramer
      54361b42
  9. 11 Jun, 2001 1 commit
    • Bruce Momjian's avatar
      Got two patches that were found by folks on the Castor list, that we'd like to · 8af0ea9d
      Bruce Momjian authored
      submit.  These were done for the jdbc2 driver.  The first one is for support
      of the Types.BIT in the PreparedStatement class.  The following lines need to be
      inserted in the switch statment, at around line 530:
      
      
      	(Prepared statment, line 554, before the default: switch
      	case Types.BIT:
      	     if (x instanceof Boolean) {
      	          set(parameterIndex, ((Boolean)x).booleanValue() ? "TRUE" : "FALSE");
      	     } else {
      	          throw new PSQLException("postgresql.prep.type");
      	     }
      	     break;
      
      
      	The second one is dealing with blobs,
      
      	inserted in PreparedStatemant.java (After previous patch line, 558):
      	         case Types.BINARY:
      	         case Types.VARBINARY:
      	                              setObject(parameterIndex,x);
      	                              break;
      	and in ResultSet.java (Around line 857):
      	        case Types.BINARY:
      	        case Types.VARBINARY:
      	                        return getBytes(columnIndex);
      
      Ned Wolpert <ned.wolpert@knowledgenet.com>
      8af0ea9d
  10. 16 May, 2001 1 commit
  11. 16 Feb, 2001 1 commit
    • Peter Mount's avatar
      Some more updates... · cdbd27cb
      Peter Mount authored
      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.
      cdbd27cb
  12. 14 Feb, 2001 1 commit
    • Peter Mount's avatar
      Web Feb 14 17:29:00 GMT 2001 peter@retep.org.uk · bb7b7182
      Peter Mount authored
              - Fixed bug in LargeObject & BlobOutputStream where the stream's output
                was not flushed when either the stream or the blob were closed.
              - Fixed PreparedStatement.setBinaryStream() where it ignored the length
      bb7b7182
  13. 13 Feb, 2001 1 commit
    • Peter Mount's avatar
      Some more including the patch to DatabaseMetaData backed out by Bruce. · 3d21bf82
      Peter Mount authored
      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.
      3d21bf82
  14. 31 Jan, 2001 1 commit
    • Peter Mount's avatar
      Tue Jan 30 22:24:00 GMT 2001 peter@retep.org.uk · 8439a83d
      Peter Mount authored
              - 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.
      8439a83d
  15. 24 Jan, 2001 1 commit
    • Bruce Momjian's avatar
      Attached is a revised patch that removes the static SimpleDateFormat · 26e56644
      Bruce Momjian authored
      objects that Thomas pointed out might be a problem.
      
      PPS.  I have included and updated the comments from the original patch
      request to reflect the changes made in this revised patch.
      
      > Attached is a set of patches for a couple of bugs dealing with
      > timestamps in JDBC.
      >
      > Bug#1) Incorrect timestamp stored in DB if client timezone different
      > than DB.
      > The buggy implementation of setTimestamp() in PreparedStatement simply
      > used the toString() method of the java.sql.Timestamp object to convert
      > to a string to send to the database.  The format of this is yyyy-MM-dd
      > hh:mm:ss.SSS which doesn't include any timezone information.  Therefore
      > the DB assumes its timezone since none is specified.  That is OK if the
      > timezone of the client and server are the same, however if they are
      > different the wrong timestamp is received by the server.  For example if
      > the client is running in timezone GMT and wants to send the timestamp
      > for noon to a server running in PST (GMT-8 hours), then the server will
      > receive 2000-01-12 12:00:00.0 and interprete it as 2000-01-12
      > 12:00:00-08 which is 2000-01-12 04:00:00 in GMT.  The fix is to send a
      > format to the server that includes the timezone offset.  For simplicity
      > sake the fix uses a SimpleDateFormat object with its timezone set to GMT
      > so that '+00' can be used as the timezone for postgresql.  This is done
      > as SimpleDateFormat doesn't support formating timezones in the way
      > postgresql expects.
      >
      > Bug#2) Incorrect handling of partial seconds in getting timestamps from
      > the DB
      >
      > When the SimpleDateFormat object parses a string with a format like
      > yyyy-MM-dd hh:mm:ss.SS it expects the fractional seconds to be three
      > decimal places (time precision in java is miliseconds = three decimal
      > places).  This seems like a bug in java to me, but it is unlikely to be
      > fixed anytime soon, so the postgresql code needed modification to
      > support the java behaviour.  So for example a string of '2000-01-12
      > 12:00:00.12-08' coming from the database was being converted to a
      > timestamp object with a value of 2000-01-12 12:00:00.012GMT-08:00.  The
      > fix was to check for a '.' in the string and if one is found append on
      > an extra zero to the fractional seconds part.
      >
      >
      > I also did some cleanup in ResultSet.getTimestamp().  This method has
      > had multiple patches applied some of which resulted in code that was no
      > longer needed.  For example the ISO timestamp format that postgresql
      > uses specifies the timezone as an offset like '-08'.  Code was added at
      > one point to convert the postgresql format to the java one which is
      > GMT-08:00, however the old code was left around which did nothing.  So
      > there was code that looked for yyyy-MM-dd hh:mm:sszzzzzzzzz and
      > yyyy-MM-dd hh:mm:sszzz.  This second format would never be encountered
      > because zzz (i.e. -08) would be converted into the former (also note
      > that the SimpleDateFormat object treats zzzzzzzzz and zzz the same, the
      > number of z's does not matter).
      >
      >
      > There was another problem/fix mentioned on the email lists today by
      > mcannon@internet.com which is also fixed by this patch:
      >
      > Bug#3) Fractional seconds lost when getting timestamp from the DB
      > A patch by Jan Thomea handled the case of yyyy-MM-dd hh:mm:sszzzzzzzzz
      > but not the fractional seconds version yyyy-MM-dd hh:mm:ss.SSzzzzzzzzz.
      > The code is fixed to handle this case as well.
      
      Barry Lind
      26e56644
  16. 13 Jan, 2001 2 commits
    • Bruce Momjian's avatar
      Backed out: · 0651a579
      Bruce Momjian authored
      ---------------------------------------------------------------------------
      
      Attached is a set of patches for a couple of bugs dealing with
      timestamps in JDBC.
      
      Bug#1) Incorrect timestamp stored in DB if client timezone different
      than DB.
      0651a579
    • Bruce Momjian's avatar
      Attached is a set of patches for a couple of bugs dealing with · 475c1452
      Bruce Momjian authored
      timestamps in JDBC.
      
      Bug#1) Incorrect timestamp stored in DB if client timezone different
      than DB.
      
      The buggy implementation of setTimestamp() in PreparedStatement simply
      used the toString() method of the java.sql.Timestamp object to convert
      to a string to send to the database.  The format of this is yyyy-MM-dd
      hh:mm:ss.SSS which doesn't include any timezone information.  Therefore
      the DB assumes its timezone since none is specified.  That is OK if the
      timezone of the client and server are the same, however if they are
      different the wrong timestamp is received by the server.  For example if
      the client is running in timezone GMT and wants to send the timestamp
      for noon to a server running in PST (GMT-8 hours), then the server will
      receive 2000-01-12 12:00:00.0 and interprete it as 2000-01-12
      12:00:00-08 which is 2000-01-12 04:00:00 in GMT.  The fix is to send a
      format to the server that includes the timezone offset.  For simplicity
      sake the fix uses a SimpleDateFormat object with its timezone set to GMT
      so that '+00' can be used as the timezone for postgresql.  This is done
      as SimpleDateFormat doesn't support formating timezones in the way
      postgresql expects.
      
      Bug#2) Incorrect handling of partial seconds in getting timestamps from
      the DB
      
      When the SimpleDateFormat object parses a string with a format like
      yyyy-MM-dd hh:mm:ss.SS it expects the fractional seconds to be three
      decimal places (time precision in java is miliseconds = three decimal
      places).  This seems like a bug in java to me, but it is unlikely to be
      fixed anytime soon, so the postgresql code needed modification to
      support the java behaviour.  So for example a string of '2000-01-12
      12:00:00.12-08' coming from the database was being converted to a
      timestamp object with a value of 2000-01-12 12:00:00.012GMT-08:00.  The
      fix was to check for a '.' in the string and if one is found append on
      an extra zero to the fractional seconds part.
      
      Bug#3) Performance problems
      
      In fixing the above two bugs, I noticed some things that could be
      improved.  In PreparedStatement.setTimestamp(),
      PreparedStatement.setDate(), ResultSet.getTimestamp(), and
      ResultSet.getDate() these methods were creating a new SimpleDateFormat
      object everytime they were called.  To avoid this unnecessary object
      creation overhead, I changed the code to use static variables for
      keeping a single instance of the needed formating objects.
      Also the code used the + operator for string concatenation.  As everyone
      should know this is very inefficient and the use of StringBuffers is
      prefered.
      
      I also did some cleanup in ResultSet.getTimestamp().  This method has
      had multiple patches applied some of which resulted in code that was no
      longer needed.  For example the ISO timestamp format that postgresql
      uses specifies the timezone as an offset like '-08'.  Code was added at
      one point to convert the postgresql format to the java one which is
      GMT-08:00, however the old code was left around which did nothing.  So
      there was code that looked for yyyy-MM-dd hh:mm:sszzzzzzzzz and
      yyyy-MM-dd hh:mm:sszzz.  This second format would never be encountered
      because zzz (i.e. -08) would be converted into the former (also note
      that the SimpleDateFormat object treats zzzzzzzzz and zzz the same, the
      number of z's does not matter).
      
      
      There was another problem/fix mentioned on the email lists today by
      mcannon@internet.com which is also fixed by this patch:
      
      Bug#4) Fractional seconds lost when getting timestamp from the DB
      A patch by Jan Thomea handled the case of yyyy-MM-dd hh:mm:sszzzzzzzzz
      but not the fractional seconds version yyyy-MM-dd hh:mm:ss.SSzzzzzzzzz.
      
      The code is fixed to handle this case as well.
      
      Barry Lind
      475c1452
  17. 28 Dec, 2000 1 commit
    • Bruce Momjian's avatar
      Attached are patches for two fixes to reduce memory usage by the JDBC · 49740c5f
      Bruce Momjian authored
      drivers.
      
      The first fix fixes the PreparedStatement object to not allocate
      unnecessary objects when converting native types to Stings.  The old
      code used the following format:
              (new Integer(x)).toString()
      whereas this can more efficiently be occompilshed by:
              Integer.toString(x);
      avoiding the unnecessary object creation.
      
      The second fix is to release some resources on the close() of a
      ResultSet.  Currently the close() method on ResultSet is a noop.  The
      purpose of the close() method is to release resources when the ResultSet
      is no longer needed.  The fix is to free the tuples cached by the
      ResultSet when it is closed (by clearing out the Vector object that
      stores the tuples).  This is important for my application, as I have a
      cache of Statement objects that I reuse.  Since the Statement object
      maintains a reference to the ResultSet and the ResultSet kept references
      to the old tuples, my cache was holding on to a lot of memory.
      
      Barry Lind
      49740c5f
  18. 17 Apr, 2000 1 commit
  19. 18 May, 1999 1 commit
  20. 17 May, 1999 1 commit
  21. 17 Jan, 1999 1 commit
    • Bruce Momjian's avatar
      As the email posted to the announce and interfaces list, attached is a tar · 298682d9
      Bruce Momjian authored
      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
      298682d9
  22. 03 Sep, 1998 1 commit
  23. 03 Jun, 1998 1 commit
    • Marc G. Fournier's avatar
      · 85f91d0e
      Marc G. Fournier authored
      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.
      85f91d0e
  24. 20 Mar, 1998 1 commit
    • Bruce Momjian's avatar
      This patch fixes a couple of minor bugs: · 2b3bb341
      Bruce Momjian authored
      1) DatabaseMetaData.getPrimaryKeys() would fail saying that there
      is no
         table t.
      
      2) PreparedStatement.getObject() was missing some break statements,
      which
         was causing updates not to work with JBuilder (supplied by Aaron
         Dunlop).
      
      
      jdbc fixes from Peter.
      2b3bb341
  25. 11 Jan, 1998 1 commit
  26. 07 Nov, 1997 1 commit
  27. 16 Aug, 1997 1 commit