Re: [DebianGIS] postgis make template_gis
Ok thanks for the clarification - I had misinterpreted this as being a postinst
script. A separate script, as you describe here, certainly could be useful
for some users.
You could put the following 5 lines into an SQL file that would be executed
create database postgis_template template="template0";
create language plpgsql;
I don't know if anything more complicated than that would be needed. Since
it's in an SQL script, the program for accessing the database and executing
these commands is already available (i.e., psql). I suppose the benefit of
adding an additional executable script would be that it could be added to a
PATH location, so an admin wouldn't need to know the path to the
template_postgis.sql script (or the already available postgis install
scripts). Is that the objective?
On Wednesday 31 March 2010 07:35:44 Francesco P. Lovergine wrote:
> On Tue, Mar 30, 2010 at 05:40:14PM -0400, Mike Leahy wrote:
> > Hi list,
> > I know I'm perhaps coming at this from left field, but could this kind of
> > thing be made optional, or maybe put into a separate package? I recall
> > this being implemented with the windows installer in PostGIS, and I found
> > it made the installation procedure more cumbersome (e.g., it couldn't be
> > installed if you didn't have the postgres db password on hand and local
> > connections weren't trusted by default, or maybe you didn't have the
> > PostgreSQL service running at the time which would also cause it to
> > fail). However, perhaps my experience is different than others?
> Adding templating to postinst is out of question. What could be done is
> a specific script to be called by the admin to make more easy first
> steps with postgis, just in case, at his/her will.
> > Apart from that, I also wonder about what happens when PostGIS gets
> > upgraded - even for minor version? Would there be any measures taken to
> > either update the template with the appropriate update script, and/or
> > drop and recreate the template?
> > These are just questions that I have - I hope you don't mind me bringing
> > them up here. Maybe these potential issues are already taken into
> > consideration?
> Updating/upgrading is potentially a dangerous step, which could require
> dumping and restoring the db. Specific (documented) good practices need
> to be followed, something that a simple script could fail to do, one
> size does not fit all...