Thread: PGConnection vs. Connection

[Crosspost to psql-jdbc, postgis-devel and alex bodnaru]

Dear pgjdbc developers,

When backporting toe PostGIS jdbc extension to debian woody (which still
uses pgjdbc 7.2), Alex Bodnaru (PostGIS debian packager) stumbled over
the fact that the addDataType() methods are carried by the
org.postgresql.Connection class instead of the
org.postgresql.PGConnection interface in 7.3 and up.

An additional minor problem is that addDataType(String) is deprecated in
8.0 and this gives compiler warnings (and has the known class loader
related problems). This problem is minor because the old method works as
good as ever, and pgjdbc 8.0 provides the autoregistration via
driverconfig.properties so we do not strictly need addDataType() calls
at all in _most_ environments.

We're currently wondering what the best method is for supporting 7.2,
the following have come to our mind.

- 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").

- Using some kind of pgjdbc autorecognition and preprocessing (e. G. ant
  filters or C preprocessor). Because of the disadvantages regarding
  common Java IDEs (Syntax highlighting, error checking tools etc.) and
  the more complicated build process, I dislike the idea of introducing
  a separate preprocessing step in a Java project as small as PostGIS
  jdbc. But this is only my personal opinion, and you can convince me
  with appropriate arguments.

- Manage two different source trees.

- 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.

- Using our own copy of PGConnection and Connection sources during our
  build process. We could then use conn.getClass().getName() or such to
  distinct which code to call, and encapsulate the actual code in
  functor objects that get instantiated lazy, so we only load the
  class that actually fits the real connection implementation (this
  should avoid classloader trouble).

Which approach do you think to be the best one? Another question is
whether it is worth the effort to develop any complicated scheme, as
only a very few lines of code are actually affected.

Markus
--
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@logi-track.com | www.logi-track.com

Markus Schaber wrote:

> the addDataType() methods are carried by the
> org.postgresql.Connection class instead of the
> org.postgresql.PGConnection interface in 7.3 and up.

That's unfortunate :(

> - 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.

> - 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.

-O

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