On Sat, May 30, 2009 at 11:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
> The way the restore works, you would have to call the data type
> 'tsvector', and then that oid is linked around in all sort of odd places
> and you need to change them all, hence confusion.
In theory, I think it would be possible to hack around this problem by
doing the following:
1. Change the OID of 8.4's "tsvector" type to an OID that was not in use in 8.3.
2. Add a type called "tsvector83" to 8.4 using the same OID that the
"tsvector" type used in 8.3.
3. Hack pg_dump so that when dumping in upgrade mode, tsvector
references from 8.3 are emitted as tsvector83.
This would mean that you'd be on line immediately following the
upgrade, because the tsvector83 type would still be usable; it just
wouldn't have the improved performance of the new tsvector.
Unfortunately, it would also require a catversion bump (and some
programming work besides, not sure how much). Given that we are 7
months after the start of the last commitfest, which was theoretically
our final feature freeze, this is probably not realistic, but if it's
not too ugly it might be considered if a similar situation comes up
during 8.5 development.
(At the risk of beating a dead horse, note if we were upgrading the
catalog tables directly via SQL, this type of scenario could be
handled cleanly without hacking pg_dump; I repeat my earlier critique
that the pg_migrator approach consigns us to a never-ending series of
pg_dump hacks, that or having it not work very well.)
...Robert