Re: pg_migrator and an 8.3-compatible tsvector data type - Mailing list pgsql-hackers

From Greg Stark
Subject Re: pg_migrator and an 8.3-compatible tsvector data type
Date
Msg-id 4136ffa0906010810r8c4a6fax8ae78a616b94e24f@mail.gmail.com
Whole thread Raw
In response to Re: pg_migrator and an 8.3-compatible tsvector data type  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_migrator and an 8.3-compatible tsvector data type  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_migrator and an 8.3-compatible tsvector data type  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_migrator and an 8.3-compatible tsvector data type  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, May 31, 2009 at 11:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Updating the catalog tables directly via SQL"?  Good luck making that
>> work.  If you ever get it to work at all, it'll require a pile of hacks
>> that will make pg_migrator look like paradise.
>
> For clarity, I really mean "from a standalone backend", but ideally
> I'd like it to be SQL.

Keep in mind that you have catalogs in all the databases, and even in
standalone mode you need those catalogs to find the, er, catalogs.
There's a reason bootstrap mode is so limited and even then it needs
some of the catalogs to already be in place.

>> (Which is not to say that pg_migrator isn't a hack; it surely is.
>> But it looks like the least painful approach available.)
>
> Maybe.  It seems that we don't have a good way of handling datatype
> conversions.  The approaches that have been proposed for tsvector
> wouldn't work at all but for the fact that the new output function can
> handle the old internal representation, which is not something that we
> can guarantee in every case.

Well I think all we need for that is to have pg_migrator provide the
old output function wrapped up in a migrate_foo() C function.


> And, even so, they leave the database in
> a broken state until the post-migration scripts have been run.  The
> good news is that tsvector is not a datatype that everyone uses, and
> those who do probably don't use it in every table, but what happens
> when we want to change numeric incompatibly?

Or, say, timestamp...

> We really need to figure out an approach that lets us keep the old
> datatypes around under a different name while making the original name
> be the new version of the datatype.  That way people can migrate and
> be up, and deal with the need to rewrite their tables at a later time.

I do agree that having to rewrite the whole table isn't really
"upgrade-in-place".

But the work to support multiple versions of data types is more than
you're describing. You need to be concerned about things like joins
between tables when some columns are the old data type and some the
new, etc.

Ultimately people will have to convert the data types sometime.

--
greg


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch: AdjustIntervalForTypmod shouldn't discard high-order data
Next
From: Tom Lane
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type