8 Commits (28e92b89f49bef7989131a356dc24c524bcff51a)

Author	SHA1	Message	Date
Bruce Momjian	28e92b89f4	Change 'return ;' to 'return;'; remove space.	24 years ago
Bruce Momjian	f3148bef9f	JDBC indenting, comment cleanups.	24 years ago
Bruce Momjian	d2e27b0674	pgjindent jdbc files. First time jdbc files were formatted.	25 years ago
Bruce Momjian	f478692552	The attached file: SerializePatch2.tgz, contains a patch for ... 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.	25 years ago
Bruce Momjian	6f101c806b	There are a number of changes. The main ones are: ... return oid on insert handle all primitive data types handle single quotes and newlines in Strings handle null variables deal with non public and final variables (not very well, though) Ken K	25 years ago
Bruce Momjian	a4e3943b3f	Back out Gunnar R|nning jdbc changes.	26 years ago
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	26 years ago
Peter Mount	25dadc8514	Another attempt at 7.0	26 years ago
Peter Mount	4c63b257fd	Internationalisation of error messages	27 years ago
Bruce Momjian	d6e0ee6bcb	Added missing file.	28 years ago