Robert Haas wrote:
> 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.
The pg_type oids are never transfered by pg_migrator; all schema
information is transfered as pg_dump --schema stuff, i.e. ASCII.
> 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.)
We could create infrastructure to handle the 8.3 storage format but my
guess is that most people would just rather rebuild the tables.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +