- 25 Oct, 2001 1 commit
-
-
Bruce Momjian authored
-
- 10 Sep, 2001 1 commit
-
-
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
-
- 26 Aug, 2001 1 commit
-
-
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.
-
- 21 Aug, 2001 1 commit
-
-
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
-
- 12 Jul, 2001 1 commit
-
-
Bruce Momjian authored
-
- 04 Jul, 2001 1 commit
-
-
Bruce Momjian authored
object inside the initialization section instead of doing it everytime the setTimestamp method is called. Thanks to Dave Harkness for this suggestion. Barry Lind
-
- 29 Jun, 2001 1 commit
-
-
Bruce Momjian authored
Barry Lind
-
- 25 Jun, 2001 1 commit
-
-
Bruce Momjian authored
Here is a patch which inspired by Michael Stephens that should work Dave Cramer
-
- 11 Jun, 2001 1 commit
-
-
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>
-
- 16 May, 2001 1 commit
-
-
Bruce Momjian authored
is of type Object, and is null Dave Cramer
-
- 16 Feb, 2001 1 commit
-
-
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.
-
- 14 Feb, 2001 1 commit
-
-
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
-
- 13 Feb, 2001 1 commit
-
-
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.
-
- 31 Jan, 2001 1 commit
-
-
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.
-
- 24 Jan, 2001 1 commit
-
-
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
-
- 13 Jan, 2001 2 commits
-
-
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.
-
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
-
- 28 Dec, 2000 1 commit
-
-
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
-
- 17 Apr, 2000 1 commit
-
-
Peter Mount authored
-
- 18 May, 1999 1 commit
-
-
Peter Mount authored
-
- 17 May, 1999 1 commit
-
-
Peter Mount authored
-
- 17 Jan, 1999 1 commit
-
-
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
-
- 03 Sep, 1998 1 commit
-
-
Bruce Momjian authored
-
- 03 Jun, 1998 1 commit
-
-
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.
-
- 20 Mar, 1998 1 commit
-
-
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.
-
- 11 Jan, 1998 1 commit
-
-
Marc G. Fournier authored
see README_6.3 for list of changes
-
- 07 Nov, 1997 1 commit
-
-
Bruce Momjian authored
-
- 16 Aug, 1997 1 commit
-
-
Marc G. Fournier authored
-