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

Re: Avoiding explicit addDataType calls for PostGIS

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: schabios(at)logi-track(dot)com
Cc: PostGreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Avoiding explicit addDataType calls for PostGIS
Date: 2004-10-06 21:11:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-jdbc
Markus Schaber wrote:

> Both PostGIS and JTS (using the JtsGeometry Wrapper Class attached to
> this mail) support direct reading of their geometry classes via
> ResultSet.getObject(int) method.

> But it is annoying that one has to explicitly call the addDataType()
> method on every connection at startup. First, this puts PostGIS/JTS
> specific code in places that should be driver independend. Second, it
> does not play well with connection pooling (jboss etc.) as one always
> has to re-add those datatypes on any connection you get.

If your objective is to produce a driver that automatically supports the 
extra datatypes, how about a provider-properties-file approach?

i.e. when creating a new connection, the postgresql driver looks for all 
resources called (or whatever) via 
ClassLoader.getResources() and reads each in turn. They are interpreted 
as properties files, and the resulting properties drive datatype 
registration. It could also perhaps be used for other driver 
configuration, things like setting the default prepareThreshold etc. in 
the absence of URL instructions to the contrary.

Then we can distribute a stock JDBC driver that has looking something like:

Perhaps we want to interpret postgresql.<a>=<b> identically to a URL 
parameter of <a>=<b> to make it more general? This is then essentially 
your list-of-datatypes-in-URL approach, with a bit of extra flexibility 
so you can easily specify new defaults.

PostGIS/JTS can package the basic JDBC driver together with the 
appropriate extra datatype classes and a new All 
users of that driver then get the new datatypes automatically registered.

You still have the problem that the driver must be able to load the 
datatype classes from the driver's classloader, but if you're 
repackaging the driver to include extra types, I think that's acceptable 
(if you can add a, you can presumably add the 
extra classes too..)

How does that fit with what you need?

(for another example of this approach, see the JNDI resource file docs 


In response to


pgsql-jdbc by date

Next:From: Katalina MarcosDate: 2004-10-06 21:47:26
Subject: table and column's comments
Previous:From: Serguei MokhovDate: 2004-10-06 19:31:39
Subject: Translation updates:

pgsql-general by date

Next:From: Michael FuhrDate: 2004-10-06 21:56:22
Subject: Re: postgres.h location?
Previous:From: Glen EustaceDate: 2004-10-06 20:26:57
Subject: Re: Mirroring databases in v8

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