Re: pg_migrator and an 8.3-compatible tsvector data type

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type
Date: 2009-06-01 03:45:51
Message-ID: 200906010345.n513jp120239@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Sat, May 30, 2009 at 11:58 PM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-06-01 03:49:19 Re: pg_migrator and an 8.3-compatible tsvector data type
Previous Message Bruce Momjian 2009-06-01 03:43:05 Re: Win32 link() function