I agree with you, right now there are many inconveniences with postgresql inheritance, that's why I never use inheritance this way.
I usually stick to the "standard" way, for example, I create a people table, and for every people I want to insert in my database there is one row in this table, plus one row with the same id/pk (which is also a fk) in a specialized table (let's say students, teachers, whatever).
This simplifies things, because attribute definitions/defaults/constraints are always in one table. Maybe you get into some other troubles, but I find them less painfull
On Sat, 2004-06-26 at 19:30, Phil Endecott wrote:
I asked if derived tables use primary key indexes generated in the base tables that they inherit from. Franco Bruno Borghesi replied: > [the derived table] is not inheriting any indexes, neither the > primary key constraint. OK, thanks! I had come to the conclusion that it was not using the index, but I'm really surprised to hear that the primary key constraint that I define in a base table is not inherited. Are any constraints inherited? What happens if I declare a single-column primary key? What if I declare a "not null" constraint or a "check" constraint in a base table? Having to replicate the constraints and indexes for each derived table is a pain - lots of error-prone typing - but there is a more serious problem: how can I ensure that these keys are unique across all of the derived tables? (i.e. if T1 and T2 inherit from B, and B's primary key is (id,xx), then I want there to be at most one row in (T1 union T2) that has any value of (id,xx).) Is this a possible area for future enhancements? Regards, --Phil.
<<attachment: smiley-3.png>>
signature.asc
Description: This is a digitally signed message part
