Re: JDBC patch (attempt#2) for util.Serialize and jdbc2.PreparedStatement - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: JDBC patch (attempt#2) for util.Serialize and jdbc2.PreparedStatement
Date
Msg-id 200108240148.f7O1mH006466@candle.pha.pa.us
Whole thread Raw
In response to JDBC patch (attempt#2) for util.Serialize and jdbc2.PreparedStatement  ("Robert B. Easter" <reaster@comptechnews.com>)
List pgsql-patches
Your patch has been added to the PostgreSQL unapplied patches list at:

    http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

> (attempt #2) Don't use serializepatch.tgz that I sent before, use the file
> attached now to this email instead.
>
> 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.
>
> A little test program is included with the patches. ?The comments in the
> Serialize class tries to explain how all this works.
>
> Note:
> 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.
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-patches by date:

Previous
From: "Robert B. Easter"
Date:
Subject: JDBC patch (attempt#2) for util.Serialize and jdbc2.PreparedStatement
Next
From: Bruce Momjian
Date:
Subject: Re: JDBC patch for util.Serialize and jdbc2.PreparedStatement