Hey Martin, * Martin Pitt ([EMAIL PROTECTED]) wrote: > Stephen Frost [2006-02-06 20:52 -0500]: > > Looks good. Is there any need to pass the username to use to connect to > > the database as superuser? I'm guessing no but thought I might mention > > it... > > The owner can be figured out easily with pg_lsclusters or some ls > command, but indeed just passing it to the hook scripts is easier. So: > > <old version> <cluster name> <new version> <superuser> <phase>
Excellent, looks good to me.
> > This looks good, the only thing I think we need to double-check is how
> > data is handled (ie: is the data portion a seperate 'object' which needs
> > to be filtered somehow, or is it associated with the base 'object', ie:
> > table, that the data is from?). Assuming the above handles the data as
> > well as the actual object itself then it should work well.
>
> The definition and content is just one object in the list. but that
> should be a mere implementation detail that shouldn't affect the spec
> wrt. hook scripts.
Good, that does make things easier (and means you don't need to dump the
data out to get the data parts in the list to check if they're already
in the new database, etc).
> > From my point of view, I'd think a per-database hook would probably
> > better.
>
> How should that look like then? The db's are certainly in place in the
> 'finish' phase, but in the 'init' phase there are just the usual
> template[01] and postgres databases. The destination databases are
> created in the pg_restore stage.
>
> It might be possible to pre-create empty destination databases right
> before calling the hooks with phase 'init' and change the hooks to be
> per-database. But that would become much more complicated and would
> involve a lot of hacking. If it's really necessary to make hooks for
> e. g. PostGIS work properly, then I'm willing to do that. But I'm not
> familiar with the steps to set up PostGIS, what needs to be done
> roughly?
Basically it's two things: install the .so into the right place (this
can be done before any databases are created and will be done when the
package is installed) and then run a .sql script which creates all the
functions and the tables, this can be done against template1 and then be
propogated to the other databases through the templating. PostGIS also
provides an 'upgrade' script of their own but which expects to work from
a dump file directly. I'm reasonably confident that with the init and
finish hooks I'll be able to properly implement the upgrade using their
script as a reference for what needs to be changed, etc.
That's something which will need to be done when upgrading PostGIS alone
anyway.
> > An interesting question would be if there's some way to detect
> > if PostGIS is installed in a given database before running the install
> > routine on it. I guess an associated question is how template1 is
> > handled...
>
> Since the hooks can access the old cluster, they should be able to
> figure that out on their own, right?
Yup. That should work just fine.
> > Is 'init' above after all databases have been created, or
> > after each one? As I expect you understand, if template1 is created and
> > then the init scripts run (which add PostGIS to template1) then it
> > wouldn't be necessary to run the init script on the 'regular' databases.
> > In that case the init scripts could be run per-cluster, provided it's
> > run after template1 is created but before any other databases are
> > created. Know what I mean?
>
> Yes, I think that's the question I raised above. If you could get away
> with just modifying template1, I would be happy. :)
Yeah, I think I can just modify template1. The 'finish' script will end
up having the majority of the complications in it but that's ok. Will I
still be able to access the old cluster in the 'finish' script? I might
need to (for example, if a user adds something to the spatial_ref_sys
table then I may need to add it in during the 'finish' stage by looking
at what was in the old cluster and comparing it to what's in the new
cluster).
> > I was thinking about this and about upgrades. It's not uncommon for an
> > upgrade to obsolete one table such that it wouldn't exist in a new
> > install.. I'm not sure that'd actually be a problem though.
>
> Ok, then let's add that functionality when we really need it.
Sure.
Thanks!
Stephen
signature.asc
Description: Digital signature
