Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] JDBC patch (attempt#2) for util.Serialize and jdbc2.PreparedStatement

From: "Robert B(dot) Easter" <reaster(at)comptechnews(dot)com>
To: Barry Lind <barry(at)xythos(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [PATCHES] JDBC patch (attempt#2) for util.Serialize and jdbc2.PreparedStatement
Date: 2001-09-09 07:21:17
Message-ID: 01090903211701.04090@comptechnews (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-patches
A CREATE TYPE/DROP TYPE bug is reported below. DROP TYPE allows a type to be 
dropped even when it is used as a column in an existing table.

On Wednesday 05 September 2001 15:11, Barry Lind wrote:
> serialization.  Why not just use java serialization to do what it was
> intended for?  We could then store the results of the serialization in a
> bytea column, or a LargeObject, or even in a separate table as is done
> here.  However, I am unsure of the desireabilty of creating these
> additional tables.  The bigest reason I don't like the additional tables
> is that the serialized objects don't ever get deleted.
>

Using the serializable interface and writeObject routines could work well and 
the problem of deleting would be gone. I was thinking that CREATE TYPE could 
be used in Seralize.create() to make the specialized java class types in the 
database, reusing the textin and textout functions (or other appropriate 
functions):

CREATE TYPE myjavatype ( input = textin, output = textout, internallength = 
variable );

This user-defined type would be used in tables that hold the serialized 
(maybe base64 encoded) binary string. These types would be unrecognized and 
default to being (de)serialized in (get)setObject like now.

It might be possible to create some basic operators for these types with 
CREATE OPERATOR to allow =, > etc, and even the ability to index on these 
custom types. Some special functions might be required for this though, but 
gets complicated when you try to cast between types. In the end, it looks 
like each type has to have its own low-level C functions to handle casting 
and operators unless I'm overlooking something.

Changing the code to work like this has the advantage that the object is 
simpler to serialize and the deletion problem is fixed.  However, these 
pg_type entries for the java types stored would clutter the system tables. At 
some time, when classes are not stored anymore, someone would want to DROP 
TYPE. Hmm, I just noticed something odd: 

CREATE TYPE footype (input=textin,output=textout,internallength=variable);
CREATE
CREATE TABLE holdsfoo (f footype);
CREATE
\d holdsfoo
        Table "holdsfoo"
 Attribute |  Type   | Modifier
-----------+---------+----------
 f         | footype |
DROP TYPE footype;
DROP
\d holdsfoo
      Table "holdsfoo"
 Attribute | Type | Modifier
-----------+------+----------
 f         | ???  |

WOOPS! ??? bad type! Scary to try inserting something here.
(Postgres 7.1.3 and cvs do this)

However, for a table-type:

CREATE TABLE footype (t TEXT);
CREATE
CREATE TABLE holdsfoo (f footype);
CREATE
DROP TYPE footype;
ERROR:  RemoveType: type '_footype' does not exist
DROP TABLE footype;
ERROR:  DeleteTypeTuple: att of type footype exists in relation 37836

This appears to be more robust.

The advantage of the way it works right now is that the tables that are 
produced can be accessed by other non-Java programs. The problem above could 
be a consideration too.

> To the extent that this is documented, I think the feature should be
> marked as experimental with a caution that it may be changed in major
> non-backwardly compatible ways in the future.

Whoever uses it should definitely use it with caution. In the javadoc for 
Serialize I expressed this. Marking it as experimental would be ok.

I'd like to find time to read official JDBC/J2EE etc. standards documents 
sometime and see if there is a standard extension defined for this type of 
stuff (anyone know?). If so, this whole thing should be trashed and 
rewritten.  My patch, again, was just a hack to make the existing code/design 
work and at least does provide some functionality now.

Robert B. Easter

In response to

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2001-09-09 12:50:50
Subject: Bug #444: create table xy as select a,b from t_a left join t_b on cond fails in PL/pgSQL
Previous:From: pgsql-bugsDate: 2001-09-09 07:16:18
Subject: Bug #443: Problem with time functions.

pgsql-patches by date

Next:From: Barry LindDate: 2001-09-09 07:59:56
Subject: Patch to add bytea support to JDBC
Previous:From: Bruce MomjianDate: 2001-09-09 03:09:12
Subject: Re: UTF-8 patch for PgTcl (was: Patch for pl/tcl ...)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group