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 | 200905311404.n4VE4TT27860@momjian.us обсуждение исходный текст |
Ответ на | 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
Re: pg_migrator and an 8.3-compatible tsvector data type |
Список | pgsql-hackers |
Bruce Momjian wrote: > 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? OK, what ideas do people have to prevent access to tsvector columns? I am thinking of renaming the tables or something. -- 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 по дате отправления: