Обсуждение: 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