"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
havebeen brought forward from the old installation by dump and restore. This ensures that any new functions will be
availableand 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