"David E. Wheeler" <da...@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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
