Tom Lane wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
> > On Sep 20, 2009, at 8:43 AM, Tom Lane wrote:
> >> Yeah, this is a long-standing generic issue, and not really hstore's
> >> problem to fix.
>
> > So then does there need to be some documentation for how to deal with
> > this, for those doing an in-place upgrade from an existing hstore data
> > type? Or would that discussion be in Bruce's tool's docs?
>
> I'm inclined to correct the existing documentation, which says at the
> bottom of http://developer.postgresql.org/pgdocs/postgres/contrib.html
>
> After a major-version upgrade of PostgreSQL, run the installation script
> again, even though the module's objects might have been brought forward
> from the old installation by dump and restore. This ensures that any new
> functions will be available and any needed corrections will be applied.
>
> That recipe doesn't actually work for cases like this. What *would*
> work is loading the module *before* restoring from your old dump,
> then relying on the CREATEs from the incoming dump to fail.
>
> I believe we have already discussed the necessity for pg_upgrade to
> support this type of subterfuge. A module facility would be a lot
> better of course, but we still need something for upgrading existing
> databases that don't contain the module structure.
Would someone please explain what needs to be done here? This is the
original email but I can't figure out what to do about it:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01368.php
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard
drive,Christ can be your backup. +
