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.
