There was a comment earlier that was not really addressed.
What can you do with table inheritance that you can not do
with a relational implementation? Or what would work *better*
as inheritance? (you define better)
This is a genuine question, not a snarky comment. I really
want to know. This is the reason I can think of to use
inheritance: Several tables have a common set of attributes and
there is some reason for these tables to be separate AND there
is some reason for the common columns to be queried en masse.
What kinds of "some reasons" are there, though? And if my
condition for using table inheritance is lacking or misguided, what should
be the criteria for using table inheritance?
Creating indexes across tables is a project. Is it the most important
project? Will it benefit the most users? Will it benefit any users?
Theory is great and important, but if no one uses the functionality,
who cares? If these changes will enable people to use the functionality
that until now had been too much of a PITA then it might be worth
it. However, I suspect the majority of people who would use these
changes are participating in these discussions.
These features were never widely used in Illustra nor Informix although
their implementations were a little smoother imho.
To weigh in on the constraints issues, it seems problematic
that currently some constraints (check) are inherited and
others are not (foreign keys). The chcheers,oice of which ones are
or aren't is clear to people familiar with the implementation
but what about the rest of the world who just want some
consistent rule.
I also agree with the people who say, if we inherit constrainsts,
then we must be able to override them in the subtables.
I like the suggested "LOCAL" keyword, myself.
cheers,
elein
:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: elein@norcov.com (510)543-6079 "Taking a Trip. Not taking a
Trip."--anonymous
:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
