Обсуждение: inheritance
I've been reading up on what Informix and Oracle provide in the way of object support. In particular I noticed that in Informix when you SELECT on a table it by default includes all the objects of sub-classes. In other words the "*" is postgres terms is always there by default. If you just want that class only you have to say ONLY(tablename). To me this is a much better idea. In any proper OO application you would be using the "*" in postgres 99% of the time - that being the whole point of OO. Does any consideration want to be given to making the same change while there's not too many people using the inheritance feature? I realise breaking compatibility is bad, but I think this is the Right Thing. When you say "SELECT * FROM animal" it's reasonable that you be returned all elephants. To not return them is pretty strange for the uninitiated. The other thing Informix does is automatically propagate all attributes including indexes, constraints, pretty much everything to sub-classes. Again.. I think this is the right thing. Any thoughts? As for Oracle 8i, as far as I can tell it provides no support for inheritance whatsoever. The docs themselves say "Oracle doesn't support inheritance". It's a bit rich really to call it Oracle "object" in any shape or form. -- Chris Bitmead mailto:chris@tech.com.au
Chris Bitmead <chris@tech.com.au> writes: > To me this is a much better idea. In any proper OO application you would > be using the "*" in postgres 99% of the time - that being the whole > point of OO. Does any consideration want to be given to making the same > change while there's not too many people using the inheritance feature? What makes you think there's "not too many people" using inheritance? Furthermore, if we did that it would break the code of people who *didn't* think they were using inheritance, except as a means of copying table definitions (which I do a lot, btw). I don't think we can reverse the default on that at this late date. > The other thing Informix does is automatically propagate all attributes > including indexes, constraints, pretty much everything to sub-classes. > Again.. I think this is the right thing. Any thoughts? I'd be inclined to agree on that, or at least say that we ought to provide a simple way of making it happen. But the right semantics are not always obvious. For example, if the ancestor has a SERIAL column, do the derived tables get their own sequence objects or share the ancestor's? Does your answer change if the serial column was created "by hand" with a "DEFAULT nextval('some_sequence')" clause? I suspect that any way we jump on this sort of question will be wrong for some apps, so it should be possible to suppress system copying of attributes... regards, tom lane
Tom Lane wrote: > > Chris Bitmead <chris@tech.com.au> writes: > > To me this is a much better idea. In any proper OO application you would > > be using the "*" in postgres 99% of the time - that being the whole > > point of OO. And considering that the Informix OO is probably really Illustra/Postgres OO, this is most likely what PostgreSQL was meant to do in the first place. > > Does any consideration want to be given to making the same > > change while there's not too many people using the inheritance feature? > > What makes you think there's "not too many people" using inheritance? The poor shape the PostgreSQL inheriatnce (and OO in general) is in ? > Furthermore, if we did that it would break the code of people who > *didn't* think they were using inheritance, except as a means of > copying table definitions (which I do a lot, btw). This use is to real inheritance as (MS win) cooperative multitasking is to real multitasking; when you stick to it too much, you will never have the real one. > I don't think we can reverse the default on that at this late date. Maybe we should then need some other construct for _real_ inheritance? A keyword like EXTENDS or something. What does ANSI SQL3 say on inheritance? > > The other thing Informix does is automatically propagate all attributes > > including indexes, constraints, pretty much everything to sub-classes. > > Again.. I think this is the right thing. Any thoughts? > > I'd be inclined to agree on that, or at least say that we ought to > provide a simple way of making it happen. But the right semantics > are not always obvious. For example, if the ancestor has a SERIAL > column, do the derived tables get their own sequence objects or > share the ancestor's? The ancestors sequence of course (ain't I smart <grin> ;) > Does your answer change if the serial column > was created "by hand" with a "DEFAULT nextval('some_sequence')" clause? It should not, else the column would not be _relly_ inherited. And as we do not have any way change any constraits/defaults after table creation this problem could be postponed to some later date. btw, is ALTER TABLE ADD/DROP CONSTRAINT, and changing column defaults planned for 6.6 ? OTOH, I'm not sure if DROP TABLE should also drop all inherited tables too? My guess is that it should by default (disabled by ONLY ?) - what does Informix do? > I suspect that any way we jump on this sort of question will be wrong > for some apps, so it should be possible to suppress system copying of > attributes... maybe we should have a TEMPLATE in addition to INHERITS ? > > regards, tom lane