Thread: 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
> --- Greg Toombs <greg.toombs@bluebottle.com> wrote: > > > I'm trying to figure out how to nicely implement a C++ class-likesystem > > with PostgreSQL. Consider the following: > > Tables Fruit, Apple, Orange you can do this traditionally or through pg inheritance, although I do not think inheritance is well supported before 8.2. from years of experience the easiest approach and aesthetically the least satisfying approach is to put everything into the fruit table create table fruit( fruit_id integer primary key, fruit_tp varchar(12), ... ); with this approach you simply deal with whatever column's your interested in - with apples the orange specific columns are dead wood - they don't get in the way and take up no storage - you just need to learn to ignore them, maybe using views to help. you can have a fruit table plus apple and orange tables. create table fruit( fruit_id integer primary key, <common attributes> ) create table apple( apple_id integer primary key, fruit_id integer not null references fruit, <apple attributes> ) you then need to build views to join fruit with apple and oranges, because some of the apple attributes are in the fruit table. lastly you need to handle dml. for example, when you insert an apple you need to insert into the fruit and the apple table. this can be done either through your application bracketing your dml with a begin and commit, or can be done through rules (much, much cooler) (the doc on rules will hold your hand through this). ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097
chester c young wrote: >> --- Greg Toombs <greg.toombs@bluebottle.com> wrote: >> >> >> I'm trying to figure out how to nicely implement a C++ > class-likesystem > > with PostgreSQL. Consider the following: >> Tables Fruit, Apple, Orange > > you can do this traditionally or through pg inheritance, although I do > not think inheritance is well supported before 8.2. Inheritance will most likely fit your C++ class-like system better and will not need foreign keys. Inheritance has been available in postgresql for many years and I think you will find it quite stable. (Not sure if pg6.x had it but it was available in 7.x) Historically a Table in postgresql was called a class (pre-sql) which is still reflected in the system catalogs with pg_class containing the list of tables and other classes like indexes.... http://www.postgresql.org/docs/8.2/interactive/ddl-inherit.html You would then have table fruit as your base class and table oranges that inherits from fruit, giving it all the columns that fruit has plus any that are added to table oranges as well. selecting from table fruit will allow you to get all rows from table apples and table oranges but not the columns unique to the apples or oranges tables. Maybe then you'll add a table basket that has a foreign key to the fruit table....... ;-) -- Shane Ambler pgSQL@Sheeky.Biz Get Sheeky @ http://Sheeky.Biz
> > Maybe then you'll add a table basket that has a foreign key to the fruit > table....... ;-) From the inheritance link: ... A serious limitation of the inheritance feature is that indexes (including unique constraints) and foreign key constraints only apply to single tables, not to their inheritance children. This is true on both the referencing and referenced sides of a foreign key constraint. ... You can create a foreign key to the fruit table to a table basket, but this foreign key will only work for fruit that was directly inserted into the fruit table. Any fruit inserted into the Apples or Oranges table can not be referenced by the table basket. I believe that this limitation in table inheritance will not work for Greg's requirements. Having said this, it would make me very happy if I am wrong. I hate modeling data the hard way when there is a better way of doing it. ;) Regards, Richard Broersma Jr.
--- Richard Broersma Jr <rabroersma@yahoo.com> wrote: > > > > Maybe then you'll add a table basket that has a foreign key to the > fruit > > table....... ;-) > > From the inheritance link: > ... > A serious limitation of the inheritance feature is that ... it's my understanding that inheritance has become much stronger in 8.2, although it still only inherits parts of the table. when primary keys and triggers are inherited then I'll be in heaven - until then rules rule. ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
> > it's my understanding that inheritance has become much stronger in 8.2, > although it still only inherits parts of the table. True. But from what I understand, the only new feature that was added to table-inheritance was the ability to ALTER a table so that it inherits another table. Before this, I think table inheritance could only be created from the CREATE TABLE statement. Regards, Richard Broersma Jr.
Richard Broersma Jr wrote: >> Maybe then you'll add a table basket that has a foreign key to the fruit >> table....... ;-) > >>From the inheritance link: > ... > A serious limitation of the inheritance feature is that indexes (including unique constraints) and > foreign key constraints only apply to single tables, not to their inheritance children. This is > true on both the referencing and referenced sides of a foreign key constraint. > ... > > You can create a foreign key to the fruit table to a table basket, but this foreign key will only > work for fruit that was directly inserted into the fruit table. Any fruit inserted into the > Apples or Oranges table can not be referenced by the table basket. I believe that this limitation > in table inheritance will not work for Greg's requirements. > > > Having said this, it would make me very happy if I am wrong. I hate modeling data the hard way > when there is a better way of doing it. ;) You can get and store related records but the issue is that you need to maintain referential integrity yourself instead of postgresql doing it for you. So currently your right, next release or two maybe not. There is a current discussion (on hackers list) on partitioning that has been going over ways to tackle the primary / unique constraints across multiple child tables and that could lead to a solution that can be applied to this as well. Partitioning is using inheritance to spread data across multiple tables. eg you may have one table for each month's worth of data. -- Shane Ambler pgSQL@Sheeky.Biz Get Sheeky @ http://Sheeky.Biz