On 2010-12-02 01:18, Jim Nasby wrote:
On Dec 1, 2010, at 8:07 AM, Yeb Havinga wrote:
FK's cannot refer to rows in inheritance childs.
We have partially solved this issue at work. In our scenario, we're not using inheritance for
partitioning, we're using it for, well, inheriting. As part of that, we have a field in the parent
table that tells you what "type" of object each row is, and constraints on the child
tables that enforce that. We've created triggers that perform the same operations that the built-in
RI triggers do, namely grabbing a share lock on the target row. The difference is that our trigger
looks at the "type" field to determine exactly what table it needs to try and grab shared
locks on (we need to do this because the backend doesn't allow you to SELECT ... FROM parent FOR
SHARE).
That part is exactly what the current WIP patch takes care of: grabbing
share locks on the right relation.
Our solution is not complete though. Offhand, I know it doesn't support
cascade, but I think there's more stuff it doesn't do. AFAIK all of those
shortcomings could be handled with whats available at a user level though, so
someone with enough motivation could produce an entire RI framework that worked
with inheritance (though the framework would need a way to work around the
uniqueness issue).
But is 'it can be solved on the user level' enough reason to not
implement it in the server code? Foreign key and unique constraint
checking are features the server should provide.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
