[postgis-devel] geos / postgis version
dblasby at gmail.com
Thu Jul 22 10:27:59 PDT 2004
Good idea on this logging.
One thing I've always wanted to see what the ability to get the CVS
log information for the ".c" file displayable inside postgresql. A
lot of people think they're using one version, but actually using
another - this could help clear it up.
For example, the top of "postgis_fn.c" looks like this:
* $Log: postgis_fn.c,v $
* Revision 1.35 2004/04/28 22:26:02 pramsey
* Fixed spelling mistake in header text.
* Revision 1.34 2004/03/26 00:54:09 dblasby
* added full support for fluffType(<geom>)
* postgis09=# select fluffType('POINT(0 0)');
* SRID=-1;MULTIPOINT(0 0)
* Revision 1.33 2004/03/25 00:43:41 dblasby
* added function fluffType() that takes POINT LINESTRING or POLYGON
It would be good to know that the compiled version is "1.35 2004/04/28".
I dont know if this is easy or not.
On Thu, 22 Jul 2004 19:12:09 +0200, strk <strk at keybit.net> 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.
> 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
More information about the postgis-devel