Re: FK's to refer to rows in inheritance child - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: FK's to refer to rows in inheritance child
Date
Msg-id 74431A07-CEC1-48BF-A9C6-F71D12A3338B@nasby.net
Whole thread Raw
In response to FK's to refer to rows in inheritance child  (Yeb Havinga <yebhavinga@gmail.com>)
Responses Re: FK's to refer to rows in inheritance child  (Yeb Havinga <yebhavinga@gmail.com>)
List pgsql-hackers
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
itfor, well, inheriting. As part of that, we have a field in the parent table that tells you what "type" of object each
rowis, and constraints on the child tables that enforce that. We've created triggers that perform the same operations
thatthe built-in RI triggers do, namely grabbing a share lock on the target row. The difference is that our trigger
looksat the "type" field to determine exactly what table it needs to try and grab shared locks on (we need to do this
becausethe backend doesn't allow you to SELECT ... FROM parent FOR SHARE). 

Our solution is not complete though. Offhand, I know it doesn't support cascade, but I think there's more stuff it
doesn'tdo. AFAIK all of those shortcomings could be handled with whats available at a user level though, so someone
withenough motivation could produce an entire RI framework that worked with inheritance (though the framework would
needa way to work around the uniqueness issue). 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: improving foreign key locks
Next
From: Jim Nasby
Date:
Subject: Re: Proposal: First step towards Intelligent, integrateddatabase