Re: pg_migrator and an 8.3-compatible tsvector data type

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: pg_migrator and an 8.3-compatible tsvector data type
Дата
Msg-id 4136ffa0905301603o4c10d1f2t1a1df1a0d4d5df4@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_migrator and an 8.3-compatible tsvector data type  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: pg_migrator and an 8.3-compatible tsvector data type  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: explain refactoring v2
Следующее
От: Justin Carrera
Дата:
Сообщение: ruby connect