>
> create table invoice_attachment (
> check (file_class = 1),
> foreign key(ref_key) references invoice(id),
> ) inherits (file_attachment);
>
> create table order_attachment (
> check(file_class = 2),
> foreign key (ref_key) references order(id),
> ) inherits (file_attachment);
>
>
While I get your proposal I am not a developer so I cannot really comment as to the cost-benefit of implementing it but
mytake is that there is too much variety to effectively code the automation you desire (ignoring the fact that you'd
wantthe indexes to remain independent) and so it is left to the developer to specify exactly what is desired.
The real issue is that your child tables are distinct sub-types of the parent as opposed to being identical to the
parentin all ways except for the range of allowable values- which what a partition is and the driver behind the current
inheritanceimplementation. It would have been better if they had restricted partitions such that you could not add
columnsand used a syntax such as "Create Table () PARTITION OF (parent_table)" and not even attempt to support
object-likeinheritance. As it is now object-inheritance is only partially supported and so while you can fake
sub-classingthe database is incapable of properly enforcing the normal use cases.
A generally better way to implement object-inheritance is to use one-to-one tables and encapsulate using
functions/view/triggersand possibly rules.
Suggestions and ideas are encouraged but are more readily received if they at least acknowledge that there are reasons
forthe existing behavior and that any solution needs to addres more than the single problem that is driving the
suggestion,and that it generally wants to solve the problem without introducing more problems/complexity.
David J.
