Re: pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE
Дата
Msg-id 1301504143.31317.3.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE  (Noah Misch <noah@leadboat.com>)
Ответы Re: pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On tis, 2011-03-29 at 17:50 -0400, Noah Misch wrote:
> Fixing that looks clear enough, but the right fix for the typed table
> issue is less clear to me.  The pg_attribute tuples for a typed table
> will include any attributes dropped from the parent type after the
> table's creation, but not those attributes dropped before the table's
> creation.  Example:
> 
> create type t as (x int, y int);
> create table is_a of t;
> alter type t drop attribute y cascade;
> create table is_a2 of t;
> select * from pg_attribute where attrelid = 'is_a'::regclass;
> select * from pg_attribute where attrelid = 'is_a2'::regclass;
> 
> To reproduce that catalog state, the dump would need to create the
> type, create all typed tables predating the DROP ATTRIBUTE, and
> finally create typed tables postdating the DROP ATTRIBUTE.  That
> implies an extra dump entry for the DROP ATTRIBUTE with the
> appropriate dependencies to compel that order of events.  Is
> there a better way? 

Maybe we could just copy the dropped attributes from the type when the
table is created.  That might be as simple as removing the
       if (attr->attisdropped)           continue;

in transformOfType().




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Typed-tables patch broke pg_upgrade
Следующее
От: Peter Eisentraut
Дата:
Сообщение: pg_upgrade and PGCLIENTENCODING