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.
