[postgis-devel] Re: [JDBC] PGConnection vs. Connection

Markus Schaber schabios at logi-track.com
Fri Feb 11 12:51:29 PST 2005


Hi, Oliver,

Oliver Jowett schrieb:

>> - Prodiding a patch that is to be applied manually (rsp. by the debian
>>   package build process) when building for 7.2. (this is our "current
>>   practice").
> 
> That seems the simplest approach. Both the 7.2 driver and server are 
> truely ancient now -- I think having to manually apply a patch if you 
> want to run against them isn't unreasonable.

I know that it is truely ancient, but for the PostGIS JDBC extension 
developers, there are three reasons to support it: PostgreSQL itsself 
still supports 7.2, PostGIS C code supports it, and Debian sta(b)le 
comes with it.

>> - Using reflection. This could allow us per run-time distinction to use
>>   o.p.PGConnection.addDataType(Class) when running against pgjdbc 8.0,
>>   o.p.PGConnection.addDataType(String) against 7.3/7.4, and
>>   o.p.Connection.addDataType(String) against 7.2. This way we could ship
>>   a single postgis.jar that runs against all pgjdbc versions.
> 
> That seems the most flexible approach, but reflection can be a pain to 
> deal with. For the packaging case, if you are going to build "PostGIS 
> for 7.2" and "PostGIS for 8.0" as separate packages then there doesn't 
> seem like much advantage to having a single PostGIS build/jar anyway.

The reflection approach and the approach using our own files to compile 
against have the advantage that we do not need to create different jars 
for different jdbc versions, so the user does not have to bother which 
one to use. This is why we did begin to think about them at all - make 
it easy for the user. This is mainly for users that download their 
postgis.jar from somewhere and drop it into their classpath, not for the 
ones that automagically get their things resolved by .deb/.rpm package 
system.

Markus



More information about the postgis-devel mailing list