[postgis-users] PostgreSQL 7.1 support

[alexbodn at 012.net.il]

hi markus,

following your message,

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

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.

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.

should i know how to do it, i would take the last choice. but the second one is not awfully bad, either.

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

> I remember several statements from strk that 7.2 is
> the oldest supported version.

he sent me this message, too. no problem with me, it was out of standard for debian, anyway.

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

best regards,

alex
-------------- next part --------------
Hi, Alex,

alexbodn at 012.net.il schrieb:

> to compile postgis jdbc, we always need the javac, so what we need
> might be a small java program that would use the postgresql.jar from
> the classpath, and print the pgjdbc version on stdout. the output
> might serve for code preprocessing (postgis sql scripts contain
> embedded #ifdef's for cpp).
>
> also, for packaging purposes, there should be known what pgjdbc
> served to compile postgis jdbc, and the jar depends on it.

I personally do not like the hassle that introducing preprocessing into
java brings up.

There is no standard regarding preprocessing in java (I saw ANT filters,
C preprocessor, AWK, SED, Bash eval expansion and even Perl Scripts.),
and the most annoying thing is that I know no IDE or syntax highlighting
java editor that is really preprocessor aware. Automatic bug checking
and such do not work, as well as the refactoring tools.

>> As far as I know, PostGIS itsself only supports 7.2 and upper.
>
> the postgis documentation and sources show support for 7.1 and later.

Oh, that's weird, as I remember several statements from strk that 7.2 is
the oldest supported version.

Maybe the documentation should be updated.

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

It was not meant as a joke at all, as I wrote under the premise that 7.2
is the oldest server version supported by PostGIS.

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
-------------- next part --------------
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users