Re: pg_migrator and an 8.3-compatible tsvector data type

Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <bruce(at)momjian(dot)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.

Another idea would be to rename just the _column_ (not the table), but
that doesn't block SELECT * from showing the column. Another idea would
be to replace tsvector's out function, but that would affect all tables
meaning it would be hard to incrementally rebuild tables using tsvector
columns. Another idea would be to use column-level permissions to
prevent column access, but that doesn't affect super-users.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +