From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE |
Date: | 2011-03-30 16:55:43 |
Message-ID: | 1301504143.31317.3.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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().
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-03-30 17:41:31 | pg_upgrade and PGCLIENTENCODING |
Previous Message | Peter Eisentraut | 2011-03-30 16:50:12 | Re: Typed-tables patch broke pg_upgrade |