[postgis-devel] postgis_version() alias of postgis_full_version()?

[Martin Schäfer]

Strk,
 
Your proposed change to postgis_version() wouldn't affect our software. However, your proposed postgis_version() would then be equivalent to postgis_lib_version(). I hope you're not planning any changes to postgis_lib_version(), as our software IS relying on this function. We are not using postgis_full_version() at all.
 
Martin Schäfer


________________________________

From: postgis-devel-bounces at postgis.refractions.net on behalf of strk at refractions.net
Sent: Thu 15/12/2005 16:26
To: PostGIS Development Discussion
Cc: Frank Warmerdam; Paul Ramsey; Dale Lutz; Martin Schäfer; Justin Deoliveira
Subject: Re: [postgis-devel] postgis_version() alias of postgis_full_version()?



On Thu, Dec 15, 2005 at 10:29:59AM -0000, Martin Daly wrote:
> > Well, I will CC my list of known important PostGIS clients to this 
> > response: I am sure at least some of them are already using 
> > postgis_version for version switching, so care must be taken, but 
> > perhaps these guys can provide some guidance to how they are parsing 
> > the string.
>
> We too use postgis_version, but only if postgis_lib_version fails, and do a simple sscanf on the result.  As long as the first part of the returned string was major.minor[.build], our code should be OK.
>
> So, provided that postgis_lib_version remains, we should be OK.  If either postgis_lib_version or postgis_version (iif postgis_lib_version failed) returned any non-blank characters before the "major" number, then we would be in trouble.
>

What I have in mind for postgis_version() is having it return *only*
release version (included MICRO)

        [CURRENT OUTPUT]
        1.1 USE_GEOS=1 USE_PROJ=1 USE_STATS=1

        [PROPOSED OUTPUT]
        1.1.0

All other info would possibly be broken (not checked at runtime)
and would show up complete with versions in postgis_full_version().
This should work for your specific case.

As for postgis_full_version() I don't have a clear plan yet
(just possibly collapsing DBPROC and RELPROC in a single output
when they match). If you can tell what are requirements for this
as well that'd be nice (it *has* non-blanks before major):

        [CURRENT OUTPUT]
        POSTGIS="1.1.0" GEOS="3.0.0-CAPI-1.0.2" PROJ="Rel. 4.4.8, 3 May 2004" USE_STATS DBPROC="0.3.1" RELPROC="0.3.1"

Thanks.

--strk;
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 6163 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20051215/bcac38f9/attachment.bin>