Richard Broersma Jr wrote:
Maybe then you'll add a table basket that has a foreign key to the fruit
table....... ;-)
From the inheritance link:
...
A serious limitation of the inheritance feature is that indexes (including
unique constraints) and
foreign key constraints only apply to single tables, not to their inheritance
children. This is
true on both the referencing and referenced sides of a foreign key constraint.
...
You can create a foreign key to the fruit table to a table basket, but this
foreign key will only
work for fruit that was directly inserted into the fruit table. Any fruit
inserted into the
Apples or Oranges table can not be referenced by the table basket. I believe
that this limitation
in table inheritance will not work for Greg's requirements.
Having said this, it would make me very happy if I am wrong. I hate modeling
data the hard way
when there is a better way of doing it. ;)
You can get and store related records but the issue is that you need to
maintain referential integrity yourself instead of postgresql doing it
for you.
So currently your right, next release or two maybe not. There is a
current discussion (on hackers list) on partitioning that has been going
over ways to tackle the primary / unique constraints across multiple
child tables and that could lead to a solution that can be applied to
this as well.
Partitioning is using inheritance to spread data across multiple tables.
eg you may have one table for each month's worth of data.
--
Shane Ambler
[EMAIL PROTECTED]
Get Sheeky @ http://Sheeky.Biz
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
