[postgis-devel] geos / postgis version

[strk]

I've added bool postgis_uses_stats() function to report
the library configuration. Note that stats usage
activation/disactivation is handled in library only 
(not scripts).
Also, I've assigned a version to postgis enabler script
(1.0.0 - can be changed).
So now we have:

  postgis_lib_version(); -- reports version of postgis lib 

  postgis_geos_version(); -- reports version of GEOS lib (NULL if disabled)

  postgis_proj_version(); -- reports version of PROJ lib (NULL if disabled)

  postgis_uses_stats(); -- boolean, are stats used ?

  postgis_scripts_version(); -- which version of postgis pl/pgsql and sql
				functions are shipped with current release ?

Note that all 5 functions are 'C' functions and are updated as you
recompile postgis. 

Now, geos, proj and stats usage build-time configurations do not change
postgis scripts in any way, so this information is not useful to detect
mimatches between library and scripts versions.

I've given (as a proposal) postgis_scripts a different version then
postgis_lib because in this way we have more ways to encode type
of changes incurred. For example we might use libtool versioning scheme
to encode interfaces additions (new functions), bug fixes and semantic
changes (old interfaces drop?). Also postgis scripts might not change
at all between postgis releases (can this really happen ?).

Anyway, if you think this is not too complicated I'll go ahead with that,
otherwise we can just have postgis_scripts_version() return
postgis release so to be able to detect bare mismatch
Eg:
	SELECT 'postgis lib/scripts mismatch' WHERE
		postgis_lib_version() != postgis_scripts_version();
	-- just need to find out how to cstring=>text or text=>cstring
	-- cast

Comments welcome.

--strk;

On Sat, Jul 24, 2004 at 12:10:26AM +0200, strk wrote:
> I've added postgis_proj_version() function, so we now have:
> 
> postgis_lib_version(); -- reports version of postgis lib 
> postgis_geos_version(); -- reports version of GEOS lib (or NULL)
> postgis_proj_version(); -- reports version of PROJ lib (or NULL)
> 
> These 3 functions should give complete library capabilities
> information.
> 
> Now. Common problem is that you used postgis.sql from an older
> postgis release and you upgraded only the library. This can now
> be detected. The function postgis_version() is an 'sql' function
> so it will NOT depend on libpostgis. This function reports:
> 
> 	- wheter GEOS has been enabled.
> 	- wheter PROJ has been enabled.
> 	- postgis release the enabler came from.
> 
> We should find out when a postgis function definition set
> (postgis.sql) is incompatible with the postgis library or
> just old in respect to the library.
> 
> Actually there are currently no cases of incompatibility 
> AFAIK, but more often you have a bogus 'sql' file and a good
> library. We could assign a version number to the 'sql'
> file, and have two functions report it: an 'sql' function
> and a 'C' function. Comparing the two will give us an hint
> about incompatibility/missing_features/missing_bugfix.
> 
> Ideas? Comments?
> 
> --strk;
> 
> On Thu, Jul 22, 2004 at 07:12:09PM +0200, strk wrote:
> > Ok, geos::version() has been split in geos::geosversion()
> > and geos::jtsport().
> > 
> > Postgis postgis_geos_version() will report geos version only
> > (I don't think we need to know JTS equivalent...)
> > 
> > I won't make the postgis_scripts_version() function now, as
> > I think it requires a deeper though about how it is supposed
> > to be used... If we need it to detect an incongruency between
> > pl/pgsql,sql functions and library functionalities we need to
> > understand what makes an incongruency and what does not.
> > 
> > --strk;
> > 
> > On Thu, Jul 22, 2004 at 06:20:45PM +0200, strk wrote:
> > > I've added postgis_lib_version() and postgis_geos_version().
> > > Before proceeding it might be worth changing geos::version()
> > > output (and maybe name) to be able to get GEOS version only
> > > (and geos::jtsport() addition...).
> > > 
> > > Any hint on proj4 version string extraction is appreciated
> > > (with back-compatibility in mind).
> > > 
> > > NOTE that postgis_lib_version also reports micro version
> > > which is actually not used in library file name (this is
> > > built using postgresql rule, which do not take a micro version
> > > number). Remember to upgrade SO_MICRO_VERSION between releases.
> > > 
> > > --strk;
> > > 
> > > On Thu, Jul 22, 2004 at 08:24:59AM -0700, Paul Ramsey wrote:
> > > > I think it is wise, and you should look at one of the emails today, 
> > > > which suggested reporting out versions of the libraries we are using 
> > > > (geos,proj) in addition to whether we have them.
> > > > 
> > > > strk wrote:
> > > > >Current postgis_version() function is implemented as a pl/pgsql
> > > > >function. Sometimes people upgrade postgis library w/out upgrading
> > > > >pl/pgsql functions, and this is *sometimes* a problem.
> > > > >
> > > > >I think it would be useful to have the following informations
> > > > >retrivable:
> > > > >	postgis_scripts_version();	// pl/pgsql  function
> > > > >	postgis_lib_version();		// C function
> > > > >	postgis_geos_version();		// C function
> > > > >
> > > > >Our postgis_version() would then be a wrapper, retriving the above
> > > > >informations and warning user in case
> > > > >postgis_scripts_version() != postgis_lib_version()
> > > > >
> > > > >What do you think ?
> > > > >
> > > > >--strk;
> > > > >_______________________________________________
> > > > >postgis-devel mailing list
> > > > >postgis-devel at postgis.refractions.net
> > > > >http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > > > 
> > > > _______________________________________________
> > > > postgis-devel mailing list
> > > > postgis-devel at postgis.refractions.net
> > > > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > > _______________________________________________
> > > postgis-devel mailing list
> > > postgis-devel at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel