Re: pg_migrator and an 8.3-compatible tsvector data type
От | Bruce Momjian |
---|---|
Тема | Re: pg_migrator and an 8.3-compatible tsvector data type |
Дата | |
Msg-id | 200905301723.n4UHNow28816@momjian.us обсуждение исходный текст |
Ответ на | 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
Re: pg_migrator and an 8.3-compatible tsvector data type Re: pg_migrator and an 8.3-compatible tsvector data type Re: pg_migrator and an 8.3-compatible tsvector data type |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > I have discovered a simpler solution using ALTER TABLE and calling a > > conversion function: > > > test=> CREATE TABLE tsvector_test(x tsvector); > > CREATE TABLE > > test=> ALTER TABLE tsvector_test ALTER COLUMN x TYPE tsvector > > test-> USING conversion_func(x); > > ALTER TABLE > > > No need for a fake data type and the required index infrastructure. > > 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? While we can mark indexes as invalid (which we do), how do we mark a table's contents as invalid? Should we create rules so no one can see the data and then have the ALTER TABLE script remove the rules after it is rebuilt? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: