Re: [HACKERS] inheritance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Bitmead <chris(at)tech(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: [HACKERS] inheritance
Date: 1999-07-21 14:59:36
Message-ID: 1812.932569176@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-sql

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. 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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message George Young 1999-07-21 15:07:10 Re: [SQL] bad select performance fixed by forbidding hash joins
Previous Message Leon 1999-07-21 14:57:38 Re: [GENERAL] OID IS INVALID?

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-07-21 15:10:13 Re: [HACKERS] Bug tracking
Previous Message Tom Lane 1999-07-21 14:42:43 Re: [HACKERS] psql & query string length

Browse pgsql-sql by date

  From Date Subject
Next Message George Young 1999-07-21 15:07:10 Re: [SQL] bad select performance fixed by forbidding hash joins
Previous Message Tom Lane 1999-07-21 13:38:13 Re: [SQL] Bad update performance?