Re: Inheritance - Mailing list pgsql-hackers

On Fri, 2002-09-06 at 03:19, Greg Copeland wrote:
> On Thu, 2002-09-05 at 08:15, Hannu Krosing wrote:
> > On Thu, 2002-09-05 at 11:34, Curt Sampson wrote:
> > > On 5 Sep 2002, Hannu Krosing wrote:
> 
> > > If that
> > > trigger is acting as an integrety constraint on the base table,
> > > you might destroy the table's integrity.
> > 
> > What I try to say is that you should have the same freedom with triggers
> > that you have with select/insert/update/delete - you must be able to
> > choose if the trigger is on the parent table ONLY or on parent and all
> > children. 
> 
> Sounds like a mechanism to make the distinction between virtual (child
> can override parent) and non-virtual (child is constrained by the
> parent) constraints are needed.
> 
> After all, there are two basic needs for constraints.  One is for
> relational integrity and the other is business rule integrity.  That is,
> one seeks to ensure that the database makes sense in respect to the data
> model (a shoe is a product) while the other is to enforce business rules
> (products are never free).  Seems like the DBA should be able to dictate
> which domain his constraint falls into in some manner.
>
> > And you should be able to override a trigger for child table even if
it
> > is defined on parent as applying to all children - I guess that
> > overriding by trigger _name_ would be what most people expect.
> > 
> 
> That's the reason I used virtual and non-virtual above.  If we think
> using C++ idioms, the child is stuck with it if it's deemed
> non-virtual.  Generally speaking, if someone designed something with
> that expectation in mind, there's probably a good reason for it.  In
> this case, we could assume that such non-virtual constraints would be to
> help ensure proper RI.  Something that otherwise, IMO, would be tossed
> out with the bath water.

I agree to this.

What I described (making overriding decision solely in child) is
probably a bad idea.

> > What I'm after here is dynamic (and automatic) row level dispach of the
> > right function based on row type - so that for rows in CITIZEN or
> > CIVIL_SERVANT the function kills_not_others(CITIZEN) will be used but
> > for rows in MILITAY the kills_not_others(MILITARY) is used.
> 
> I think we're touching on some form of RTTI information here.  That is,
> triggers and even functions may need to be able to dynamically determine
> the row type that is actively being worked on.

Should be easy if the row comes directly from a table : just use
tableoid column.

> If we're on the same page, I think that seemingly makes a lot of sense.
> 
> What about the concept of columns being public or private?  That is,
> certain columns may not be inherited by a child?  Any thought to such a
> concept?  Perhaps different types of table inheritance can be considered
> in our model...has-a, is-a, etc...

I can't fit this in my mental model of table inheritance for two reasons

1) all parent table columns must be present in child

2) granting some right to parent should automatically allow selecting
from children

both are required for select/insert/update/delete to work on table and
its children (i.e. without ONLY)


But maybe i just need to think more about it ;)

------------------
Hannu