> What's really the difference between this and creating separate tables
> with the same column definition without the inherit, and then create a
> view to "merge" them together?

Easier syntax for queries.   If you created completely seperate tables and 
UNIONED them together, you'd have to be constantly modifying a VIEW which 
tied the tables together.  With inheritance, you just do "SELECT * FROM 
parent_table" and it handles finding all the children for you.

> Also, I've run into a snag in that I have a hourly_detail table, that
> has a foreign key to the hourly_report_data.  The inherit method above
> does not honor the foreign key relationship to the children table of
> hourly_report_data.  I can't insert any data into the hourly_detail
> table due to the constraint failing.

This is a known limitation of inherited tables, at least in current 
implementations.   I think it's on the TODO list.   For now, either live 
without the FKs, or implement them through custom triggers/rules.

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to