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