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

On Wed, Mar 30, 2011 at 10:14:03AM -0400, Robert Haas wrote:
> On Tue, Mar 29, 2011 at 5:50 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > 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?
>
> I think so. We have this same problem with regular table inheritance,
> and the way we fix it is to jigger the tuple descriptor for the child
> table so that it matches what we need, and THEN attach it to the
> parent:
<snipped example>
> I think we need to do something similar here -- use the same hack
> shown above to get the dropped column into the right state, and then
> jigger things so that the child is a typed table associated with the
> parent.

Good idea; I agree.

> Perhaps it would be reasonable to extend ALTER TABLE .. [NO]
> INHERIT to accept a type name as the final argument. If used in this
> way, it converts a typed table into a regular table or visca versa.

Why extend ALTER TABLE ... INHERIT? I would have guessed independent syntax.

> We could also do it with a direct catalog change, but there are some
> dependencies that would need to be frobbed, which makes me a bit
> reluctant to go that way.

Agreed; it's also an independently-useful capability to have.