JDBC patch for util.Serialize and jdbc2.PreparedStatement (attempt #2)

I submitted an "attempt#2" or "take 2" of a patch to fix the util.Serialize
and jdbc2.PreparedStatement classes so that the serializing of a java class
into the database works more that it did before.

The code to "serialize" a java class instance into a table in the database
has existed in the jdbc source code for a long time according to the comments
I read in the source code. However, when I tried to use this stuff it didn't
work at all. So, I hacked on it some and made some relatively simple fixes
and got it to work. There lots of restrictions on what java class can be
serialized and how you need to write it though: see the source code comments
for the Serialize.java (see pgsql-patches list or the unapplied patches list)
file in my patch or in cvs if it is applied.

The serialize code executes as a result of calling jdbc2.PreparedStatement
setObject(int, Object), where Object is some unrecognized type. setObject
defaults to trying to "serialize" an Object if no if/else case matches first.
This results in an instance of Serialize being initialized for the class of
Object and in Serialize's constructor, it queries pg_class to find a relname
that matches the name of the java class. If found, the table is attempted to
be used to store or fetch instances of the java class. This table will not
exist unless it is first initialized once by calling
Serialize.create(conn,Object) first ( unless by some freak chance a table
with the right name already existed and is used unintentionally!).

Again, read the source code comments in Serialize.java. Because there are so
many restictions/limitations about it, it might not be all that useful in its
present form. A better serialize method might be to use the standard java
Serializable interface stuff more to get a binary string representation of
the class instance and store it in the database in whatever kind of field
postgres can hold a binary string in (hopefully something other than a large
object). Whatever its limitations, it might be nice for some use if tested
more and debugged enough. I don't claim it to be bug free! There is some
code in the Serialize create method that attempts to recursively convert
fields of a class into a bunch of tables, but I did not write that code nor
test it.

Making it work involved using a table as a data type: something that postgres
supports, but not completely. The tablerow-as-type type has no support
operators or functions for even simple things like casting or comparing, so
it can't do anything but serve as a type identifier. An oid field is still
needed along with this tabletype id field. The oid number and the number
value stored in a tablero-type field are the same; they are just different
datatypes: one is of type oid, which you can do useful things with, and the
other of type mytable or whatever which postgres won't let you much of
anything useful with.

Like the old comment in Serialize.java said, it is complex to explain, but
actually it is simple.

On Thursday 23 August 2001 17:37, Rene Pijlman wrote:
> On Thu, 23 Aug 2001 14:37:27 -0400, you wrote:
> >a patch [...] 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.
>
> I would appreciate it if you would explain to us a little more
> what does and doesn't work before and after applying this patch.
>
> [jdbc-list added to the CC]
>
> Regards,
> René Pijlman
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster