pg_migrator and making columns invisible

Lists: pgsql-hackers
From: Bruce Momjian <bruce(at)momjian(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: pg_migrator and making columns invisible
Date: 2009-06-02 13:54:52
Message-ID: 200906021354.n52Dsqa29305@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

pg_migrator requies tables using tsvector data types to be rebuilt, and
there has been discussion of how to prevent people from accessing those
columns before they are rebuilt. We discussed renaming the tables
(affects all columns) or columns, using rules (not fine-grained enough),
or using column permissions (doesn't affect super-users).

My new idea is to mark the column as "dropped" and unmark them before
rebuilding the table. That might be the best I can do. Comments?

--
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. +


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: pg_migrator and making columns invisible
Date: 2009-06-02 14:07:11
Message-ID: 200906021407.n52E7Bx06695@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian wrote:
> pg_migrator requies tables using tsvector data types to be rebuilt, and
> there has been discussion of how to prevent people from accessing those
> columns before they are rebuilt. We discussed renaming the tables
> (affects all columns) or columns, using rules (not fine-grained enough),
> or using column permissions (doesn't affect super-users).
>
> My new idea is to mark the column as "dropped" and unmark them before
> rebuilding the table. That might be the best I can do. Comments?

FYI, one big problem with this is that if they rebuild the table before
dropping the columns the data is lost. It seems leaving the data around
as invalid might be safer.

--
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. +


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_migrator and making columns invisible
Date: 2009-06-02 14:29:08
Message-ID: 11718.1243952948@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> pg_migrator requies tables using tsvector data types to be rebuilt, and
> there has been discussion of how to prevent people from accessing those
> columns before they are rebuilt. We discussed renaming the tables
> (affects all columns) or columns, using rules (not fine-grained enough),
> or using column permissions (doesn't affect super-users).

> My new idea is to mark the column as "dropped" and unmark them before
> rebuilding the table. That might be the best I can do. Comments?

You're expending a lot of work on solving the wrong problem. The right
solution is a temporary data type.

regards, tom lane


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_migrator and making columns invisible
Date: 2009-06-02 15:17:45
Message-ID: 200906021517.n52FHjc08861@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > pg_migrator requies tables using tsvector data types to be rebuilt, and
> > there has been discussion of how to prevent people from accessing those
> > columns before they are rebuilt. We discussed renaming the tables
> > (affects all columns) or columns, using rules (not fine-grained enough),
> > or using column permissions (doesn't affect super-users).
>
> > My new idea is to mark the column as "dropped" and unmark them before
> > rebuilding the table. That might be the best I can do. Comments?
>
> You're expending a lot of work on solving the wrong problem. The right
> solution is a temporary data type.

How do cleanup all references to the tsvector data type? I am afraid
there will be tons of tsvector references outside tables that I can't
clean up.

--
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. +