| From: | Greg Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | 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-05-30 23:03:17 |
| Message-ID: | 4136ffa0905301603o4c10d1f2t1a1df1a0d4d5df4@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Carrera | 2009-05-31 00:46:13 | ruby connect |
| Previous Message | Robert Haas | 2009-05-30 21:33:07 | explain refactoring v2 |