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