Re: Inheritance Algebra - Mailing list pgsql-general

From Karsten Hilbert
Subject Re: Inheritance Algebra
Date
Msg-id 20051223140147.GA5629@merkur.hilbert.loc
Whole thread Raw
In response to Re: Inheritance Algebra  (Trent Shipley <tshipley@deru.com>)
Responses Re: Inheritance Algebra
List pgsql-general
On Thu, Dec 22, 2005 at 05:05:49PM -0700, Trent Shipley wrote:

> On Wednesday 2005-12-21 07:50, Karsten Hilbert wrote:

> > I would assume quite a few people would use table
> > inheritance in a simple way were it available in a more
> > convenient fashion: to transport fields, primary and foreign
> > keys to child tables.
>
> I am not clear on why this sort of scenario benefits more from CREATE TABLE's
> "INHERITS" clause than the "LIKE" clause
Because the inherited fields are aggregated in the parent
table.

Imagine a database:

create table narrative_base (
    narrative text
);

create table memo (
    author text default CURRENT_USER
) inherits (narrative_base);

create table ads (
    fk_campaign integer references campaigns(pk)
) inherits (narrative_base);

... more child tables

... even more child tables

Then we go on merrily inserting all sorts of stuff into the
narrative_base child tables for two years.

Now the boss asks me: "Has anyone ever written anything with
'PostgreSQL' in it in our company ?"

So I go

 select tableoid, * from narrative_base where narrative ilike '%postgresql';

et voila. I don't have to remember all the tables
potentially containing narrative and join them.

Now, if this properly transporter primary and foreign keys
to child tables I could add

    pk serial primary key

to narrative_base and be done with primary keys for all
children.

Get the drift ?

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

pgsql-general by date:

Previous
From: Ragnar
Date:
Subject: Re: Stored procedure
Next
From: Mike Rylander
Date:
Subject: Re: Inheritance Algebra