Re: pg_migrator and an 8.3-compatible tsvector data type

Greg Stark wrote:
> On Sat, May 30, 2009 at 6:23 PM, Bruce Momjian <bruce(at)momjian(dot)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.

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.

--
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. +