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 по дате отправления: