Don,
> 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])
