Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id E192F477171 for ; Wed, 29 Jan 2003 15:49:32 -0500 (EST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178]) by postgresql.org (Postfix) with ESMTP id 4862F47716E for ; Wed, 29 Jan 2003 15:49:32 -0500 (EST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id F0F20D605; Wed, 29 Jan 2003 12:49:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id E6A545C02; Wed, 29 Jan 2003 12:49:27 -0800 (PST) Date: Wed, 29 Jan 2003 12:49:27 -0800 (PST) From: Stephan Szabo To: Neal Lindsay Cc: Subject: Re: Inheritence and Integrity In-Reply-To: Message-ID: <20030129124738.K14721-100000@megazone23.bigpanda.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200301/491 X-Sequence-Number: 11356 On Wed, 29 Jan 2003, Neal Lindsay wrote: > Stephan Szabo wrote: > > On Wed, 29 Jan 2003, Neal Lindsay wrote: > >>I am creating a database that will keep track of several different types > >>of 'events'. I am toying with the idea of making a base 'class' table > >>for the tables because a lot of the information will be the same (also > >>there will probably be times I just need to get the basic information > >>about events regardless of their type). My question is: will triggers > >>and rules on the parent table fire when I insert data in the child > >>tables? Are there any other potential pitfalls? > > > > > > Currently that won't do what you want because triggers are not inherited > > and the constraint is set up so the references constraint ends up being > > only on the rows in parenttable. In addition, the primary key constraint > > won't do what you probably want either, although since it's a serial, you > > won't be likely to notice. > > > > So what you're saying is that I could insert a duplicate primary key > into the parent table by inserting an explicit value in that field in my > child table? And if I leave that column out of my insert statement the > "default nextval()" will still make it a unique value? Well, the children have no unique constraint at all as defined. But if you pretty much only ever insert using the default it's fine since the nextval() will give unique values. > If that is so, is there a way to make constraint that will keep primary > keys unique across all the child tables of my parent table? I don't know of an easy way. Possibly some kind of ugly trigger thing.