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

Register arbitrary types Framework

From: Markus Schaber <schabios(at)logi-track(dot)com>
To: PostGreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Register arbitrary types Framework
Date: 2004-03-10 16:49:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Hello @all,

I don't know whether this List is the correct place to ask this, and so
I added an similar Feature Request to the gborg project:

For my project, I need to register third-party classes as postgres
classes, (specifically, I want JTS objects to be directly created when
calling getObject(int)) and it is not eligible to patch those
third-party classes.

However, the current user-type register system only allows subtypes of
PGObject to be registered. I have two Ideas on how to change this,
whereas I would prefer the second one, and am willing to write and
provide patches for both of them if they are to be accepted:

- When a registered object is no subclass of PGObject, use the
constructor that uses a single String as arguments for reading and
toString() for writing.

- Allow instances of a factory Interface to be registered to the
PostGreSQL connection. Then, when reading this type, a creator function
of the factory is called, and when writing, we can use a map to find the
factory from the object's class.

At least the second solution would also allow cleaning up of the PostGIS
jdbc drivers as they now use a PGGeometry class that acts as a pure
Wrapper function, and the user has to call getGeometry() on the received
PGGeometry to get the real Geometry.

Thanks for your patience,

markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 z├╝rich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios(at)logi-track(dot)com |


pgsql-jdbc by date

Next:From: Dave CramerDate: 2004-03-10 19:15:39
Subject: Re: Backup of users and groups?
Previous:From: Richard BottomsDate: 2004-03-10 16:34:16
Subject: Re: two dimensional arrays supported?

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