From: Bruce Momjian on 22 Feb 2010 21:23 Tom Lane wrote: > "David E. Wheeler" <david(a)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(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: commented out para in docs Next: [HACKERS] function side effects |