Re: [HACKERS] inheritance

Tom Lane wrote:
>
> Chris Bitmead <chris(at)tech(dot)com(dot)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