Re: Referential Integrity problem

From: James Gregory <james(at)anchor(dot)net(dot)au>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: PostgreSQL general list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Referential Integrity problem
Date: 2003-03-19 11:26:50
Message-ID: 1048073210.30662.23.camel@pirate.bridge.anchor.net.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 2003-03-19 at 00:08, Stephan Szabo wrote:
> On 19 Mar 2003, James Gregory wrote:
>
> > I hope this one is just some misunderstanding on my part.
>
> Referential integrity constraints currently apply only to the explicitly
> named table. In addition, the saleable_item primary key on id is not
> inherited by product (and so there can be duplicates in product - even if
> you put a unique constraint on product(id), you still can have duplicates
> between saleable_item and product).

Ar. Is there a way to do what I need to do? No insertions should ever
occur in the "supertable" - is the best way forward to write a trigger
that just tests if the id exists in the supertable? With this assertion
that no inserts will occur in the supertable, is it sufficient to
qualify my references to say saleable_item.id?

This behaviour seems inconsistent (to me anyway). Is it likely to
change? Why isn't the primary key inherited?

Am I correct then in my understanding that postgres's inheritance is
merely a table templating system rather than inheritance, per se? - that
is, it seems to me that if it were inheritance that storing a list of
saleable_items and filling it with products should be entirely
equivalent to storing a list of products. Why is this not so?

Thanks for your help,

James.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message James Gregory 2003-03-19 13:06:22 Re: Referential Integrity problem
Previous Message Bruno Wolff III 2003-03-19 11:13:14 Re: Division of intervals.