On Sat, May 30, 2009 at 11:58 PM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
