[postgis-users] PostgreSQL 7.1 support

[Markus Schaber]

Hi, Alex,

alexbodn at 012.net.il schrieb:

>> I personally do not like the hassle that introducing preprocessing
>> into java brings up.
> 
> what i meant by preprocessing, is to set the controversive lines in
> the java program according to the pgjdbc version in the makefile.
> this will work as patch, just more reliably. of course, that would
> mean to keep the not processed code in a not pure java language.

And this is some kind of preprocessing. The patch approach has the
advantage that the .java file still is in pure java. The question is
whether we can get this result via different means without breaking the
java syntax.

BTW, why do you think the patch method is not reliable?

> the more purist solution, would be to fully isolate the version
> differences in a java file outside the main code, and keep two
> versions. the make processing should install only the appropriate
> one.

As the differences are rather small (see the patch), I think managing
two different versions is not worth the effort.

> the most purist solution would also isolate the code options in
> another class, that would just fail when trying to activate the code
> for the wrong version. i am not a java programmer, but i hope the
> language might support such construct. although the runtime choice
> might be a performance penalty, this code is been activated very
> scarcely.

I think it may be possible to achieve this using reflection and a
Functor-like approach. This way we could even create a single jar file
that works with both jdbc variants. But we would need both jdbc variants
at compile time (or deliver our own derived Stub files of them with
PostGIS for compilation that must not be packed into the jar).

I'll do some further experimentation on that.

> anyway, please expose the program to display the pgjdbc version.

The "TestAutoregister" class does so, a standalone app would be the
following:

-- snip --
package examples;

public class DisplayJDBCVersion {
    public static void main(String[] args) {
        System.out.println("Driver version: " +
org.postgresql.Driver.getVersion());
    }
}
-- snap --

>>> Is there any real need to use a pgjdbc 7.1 jar against a 7.2
>>> server running PostGIS?
>> 
>> nice joke. i would rather think pgjdbc 7.1 with pgsql 7.1.
> 
> as pgjdbc is usually been made after pgsql, and you have already
> stated that newer pgjdbc might work with older pgsql (like pj80 with
> pg74, pj73 with pg72), i just thought that pj71 with pg72 was a real
> joke of yours. not the least intention to ofend you.

PostgreSQL is backwards compatible to older clients (at least some
versions), so it should be possible to run pj71 with pg72. It usually is
a bad idea to force client driver updates to be equal to server updates.

PostGIS breaks this rule, but for a very good reason, and the "official"
way to access data via OpenGIS functions should work as before.

Some details wr/t compatibility: Not every PostgreSQL release uses a new
protocol. Supporting the same protocol means clients and server are
compatible. Both 7.4 and 8.0 servers use V3 protocol, but still support
V2 protocol connections as well. Server versions 7.1, 7.2 and 7.3 use V2
only. On the client side, jdbc7.4 and 8.0 know about both the V2 and V3
protocol, while 7.1, 7.2 and 7.3 support V2 only. So you really can use
any jdbc from 7.1 and 8.0 against any server from 7.1 and 8.0 (minus
bugs, of course :-)

Just for curiosity, I successfully ran "make alltests" against a 7.4
server using the jdbc7.1-1.2.jar, the only necessary fix was to remove
one line of Debug output of DriverWrapper.java, line 79, as
Driver.info() seems to be missing.

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