On Wed, Mar 30, 2011 at 10:14:03AM -0400, Robert Haas wrote: > On Tue, Mar 29, 2011 at 5:50 PM, Noah Misch <n...@leadboat.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
