It is reliable but lacking in some functionality. The best thing to
do is probably just play around with it a bit. Once you realize that
children have physical copies of inherited columns (rather than get
them by joining with a parent) most of the eccentricity becomes obvious.
The syntax for inheritance is changing in PG 7.1, in the direction of
standard SQL3.
I haven't looked at the ACS 4 core yet, but for instance instead of
having to remember to include "creation_date" and "creation_user"
fields in every table you can create a base object table with such
fields and always inherit from them. Since columns are physically
created in child tables there's no performance cost for doing so. You
can also write a single query to grab (say) the creation_date from any
derived table without needing to know the name of the derived table.
So doing utility-type queries that work on any table in the system
become a possibility.
One place it seems perhaps immediately useful is in the definition of
the content repository...though in practice copying the existing pure
relational datamodel might be easier since we're not inventing this
from scratch for PG.
