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 4136ffa0905301603o4c10d1f2t1a1df1a0d4d5df4@mail.gmail.com
Whole thread Raw
In response to Re: pg_migrator and an 8.3-compatible tsvector data type  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_migrator and an 8.3-compatible tsvector data type  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Sat, May 30, 2009 at 6:23 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> I think this is basically a large-caliber foot gun.  You're going to
>> pretend that invalid data is valid, until the user gets around to fixing
>> it?
>
> What choice do we have?

Well you can store the data in a new fake data type (or even just mark
the column as a bytea -- since any varlena is as good as any other).
Then provide this conversion function to create the new data.

I suppose that means you should drop the indexes since if you leave
them things could get weird. But doing the conversion would have to
rebuild indexes anyways so CREATE INDEX should run in the same time as
that step of the conversion would have taken. It would be nice if you
could leave them around so the conversion would rebuild them
automatically, but that would require creating operators and an
opclass for the fake data type which would be more of a pain than just
marking the column as a bytea or a data type with no operators.



--
greg


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: explain refactoring v2
Next
From: Justin Carrera
Date:
Subject: ruby connect