[postgis-devel] postgis_version() alias of postgis_full_version() ?
strk at refractions.net
strk at refractions.net
Thu Dec 15 07:26:49 PST 2005
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;
More information about the postgis-devel
mailing list