[DebianGIS-dev] Re: Postgis setup

[alex bodnaru]

hi floris,

since the binary postgis utilities (presently the shp interface) are
been compiled for different postgresql api' we should indeed keep them
with the appropriate postgresql binaries, and should indeed be routed
using the PGCLUSTER directive.

fortunately, upstream developers stated that newest version of all
utilities should work for postgis 0.9 databases (see the manuals for
special switch).

thus, utilities may be separed from libraries, and, since the libraries'
names differ at major upgrades (by their file names and the sql
functions script file), we should be able to keep various versions of
the libraries and of the postgis.sql scripts for the same postgresql.

this kind of setup will be very useful to allow users to upgrade, and to
even make hybrid queries on two different databases.

of course, we should keep a default postgis to use in
/etc/default/postgis, that would be sourced in order to detect the
script to be loaded by mktemplate_gis, that will anyway be used in
following database operations.

i'll start working right now on this kind of package split, to allow
paolo to have his data on the same postgresql with different postgis.

best regards,

alex

Floris Sluiter wrote:
> Hi Alex,
> 
> 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
> postgresql/7.4/contrib etc.
> 
> 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
> like
> postgresql/8.0/contrib/postgis/0.9/
> 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.
> 
> Ciao,
> 
> Floris
> 
> 
> 
> 
>>hi,
>>
>>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.
>>
>>alex
>>
>>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
>>>that
>>>of Floris. A report later.
>>>After that, we'll try to test the tools, as requested by alex.
>>>Many thanks.
>>>pc
>>>At 04:06, mercoledì 12 ottobre 2005, alex bodnaru has probably written:
>>>
>>>
>>>>hi friends,
>>>>
>>>>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
>>>>0.9 databases.
>>>>
>>>>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.
>>>>
>>>>best regards,
>>>>
>>>>alex
>>
> 
> 
>