[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