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
