[postgis-devel] geos / postgis version
strk
strk at keybit.net
Wed Jul 28 09:19:02 PDT 2004
I've modified all version functions to return 'text', renamed
postgis_scripts_version() to postgis_scripts_installed()
(for clarity), added postgis_scripts_released() and postgis_full_version().
Here is an example usage:
=# SELECT postgis_lib_version() as release,
-# postgis_proj_version() as proj,
-# postgis_geos_version() as geos,
-# postgis_uses_stats() as stats,
-# postgis_scripts_installed() as db_proc,
-# postgis_scripts_released() as lib_proc;
release | proj | geos | stats | db_proc | lib_proc
---------+------------------------+-------+-------+---------+----------
0.8.2 | Rel. 4.4.8, 3 May 2004 | 2.0.0 | t | 1.0.0 | 1.0.0
=# SELECT postgis_full_version(); postgis_full_version
-----------------------------------------------------------------------------------------------------
POSTGIS="0.8.2" GEOS="2.0.0" PROJ="Rel. 4.4.8, 3 May 2004" USE_STATS DBPROC="1.0.0" RELPROC="1.0.0"
(1 row)
Note that postgis_full_version() output currently reports both DBPROC
and RELPROC, but could eventually just raise a warning on mismatch instead.
Comments welcome.
--strk;
On Wed, Jul 28, 2004 at 03:53:00PM +0200, strk wrote:
> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
More information about the postgis-devel
mailing list