Simon Riggs <[EMAIL PROTECTED]> writes: > On Thu, 2006-06-08 at 16:47 -0400, Tom Lane wrote: > > Greg Stark <[EMAIL PROTECTED]> writes: > > > Tom Lane <[EMAIL PROTECTED]> writes: > > >> So? They'll get re-merged with the parent column during CREATE TABLE > > >> anyway. > > > > > But merged columns that are defined locally still appear in the position > > > they > > > were defined locally. Not with the other inherited columns. > > Based on the test case Tom shows, I think we need to enforce that ADD > INHERITS will barf if the columns are not in exactly the order they > would have been in if we add done a CREATE ... INHERITS followed by a > DROP INHERITS.
Well firstly I think that rule is much too hard to explain to users. You would have to simplify it into something that makes more sense from a user's point of view. But there's a bigger problem, it won't actually help. To maintain that invariant you would never be allowed to DROP a parent unless you had no locally defined columns at all. And if you had multiple parents you would have further restrictions no multiply defined columns and you can only drop parents in the reverse order they were listed on the inherits line. So basically that rule translates into "you can only add a parent with precisely the same definition as your child table and you can only drop a parent if it's the last parent in the list and none of the columns are shared with other parents". Is that what you want? -- greg ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
