I would not advise just one set of tools:
That set-up will break the moment something changes upstream! It is not
flexible enough for the multiversion/cluster environment.
Why not do something similar to postgresql-common?
The binary tools would be located in a directory under
You need a wrapper script that will filter which shp2pgsql you need
(similar to createdb/createlang etc).
so an example call
shp2pgsql --cluster 8.0/main mytable my.shp
would be directed to the correct binary in postgresql/8.0/contrib (note
that the clustername 'main' is redundand, but not harmfull, if we only
allow one version of postgis per version of postgresql, see below)
You can copy most of the script from something that Martin wrote.
I do think it is reasonable to have only one version of postgis per
version of postgresql. So I do not think it is necessary to do something
It would be hard to detect which postgis version is needed for which
cluster in that case, but maybe somebody knows a clever solution to that.
The lwpostgis.sql should also be called from the correct location. I do
not know if it is possible to load that with createlang for instance, that
would be much better than loading it directly with psql, because in that
case the database creator needs to know which path to take. Note that
createlang already was adapted by Martin to search the correct paths.
> yes, there is no problem to have postgis coexisting for different
> postgresql versions.
> unfortunately, libpostgis0 clash with libpostgis1 on the same
> postgresql. that's because i have not separated the utilities from the
> library (waiting for your opinion whether tools from 1.0.4 can operate
> on data being handled with 0.9.2).
> the moment you tell me the utilities do that, we can have one utilities
> package (the latest), and many libpostgis#SONAME#-pg74 (which just
> differ in #SONAME#). the same with pg80.
> Paolo Cavallini wrote:
>> Hi Alex.
>> I miss a point here: is it possible to have libpostgis0-pg7.4 and
>> libpostgis1-pg8.0 on the same (multicluster) machine, or they conflict?
>> We're completing our migration, using a slightly different approach from
>> of Floris. A report later.
>> After that, we'll try to test the tools, as requested by alex.
>> Many thanks.
>> At 04:06, mercoledì 12 ottobre 2005, alex bodnaru has probably written:
>>>the moment you came with the information, the postgis project has been
>>>added a new wiki.
>>>as for the problems: i have attached the up to date postgis-0.9.2
>>>package for multiversion architectures.
>>>since i intend to make postgis 0.9 coexist with 1.0, i would be eager to
>>>know whether the tools that came with latest postgis do still support
>>>at the moment, the packages conflict because the tools are common to
>>>both of them. thus, i would recomment to install libpostgis0-pg7.4, with
>>>libpostgis1-pg8.0, to do the transition.
>>>p.s. the java package has been sent for completeness, while it has been
>>>totally upgraded in later versions.
Pkg-grass-devel mailing list