Re: [HACKERS] Inheritance, referential integrity and other constraints
От | Chris Bitmead |
---|---|
Тема | Re: [HACKERS] Inheritance, referential integrity and other constraints |
Дата | |
Msg-id | 388F9110.9816F127@bitmead.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Inheritance, referential integrity and other constraints (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Peter Eisentraut wrote: > What needs discussion is whether indexes should be shared between > inherited tables, or whether each new descendant table needs a new > one. Not sure if this just made sense, though. Shared indexes should definitely be allowed, if not the default. When you've got deep hierarchies of inheritance it makes queries slow to have to consult a whole lot of indexes. > > 1. All tables in the group must possess all the columns of their > > ancestor, and all those columns must be of the same type. > > Isn't it this way now? No, because you can do an ALTER TABLE (without the *) on the base, and it doesn't get propagated to the descendants. Possibly this should be disallowed, although it needs more thought. BTW, if I remember right, Informix/Illustra has made the "*" also include subclasses syntax the default. In other words you DON'T use the *. If you only want a particular class and not sub-classes you have to write "ONLY <classname>", or something. IMHO this is the RIGHT THING. For almost everything (eg ALTER TABLE above) you always want to include subclasses. Same goes for any random query. This is the OO way, you don't think about subclasses unless you are doing something strange. This is a pretty big change, but IMHO it should be made at some time. "*" syntax should be eliminated and made default and something like ONLY be added for when you really only want that one table. This won't affect anyone using postgres as a RDBMS, only those people using it as ORDBMS. > It's been a while since I looked into C++, but when you alter a descendant > (such as making a formerly public method private) you surely do not affect > the parents. I don't think we're talking about descendants. Rather parents. > The other way around I think the choice of star-or-not should > be given to the user. But then you can create a hierachy using ALTER that you couldn't have created using plain CREATEs. This is bad I think and also has never been done in any object system/language I've ever heard of.
В списке pgsql-hackers по дате отправления: