Re: foreign key locks, 2nd attempt

On Thu, Feb 23, 2012 at 19:44, Kevin Grittner <span dir="ltr"><<a
href="mailto:Kevin.Grittner@wicourts.gov">Kevin.Grittner@wicourts.gov</a>></span>wrote:<br /><div
class="gmail_quote"><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">One of the problems that Florian was trying to address is that<br /> people often have a need
toenforce something with a lot of<br /> similarity to a foreign key, but with more subtle logic than<br /> declarative
foreignkeys support.  One example would be the case<br /> Robert has used in some presentations, where the manager
columnin<br /> each row in a project table must contain the id of a row in a person<br /> table *which has the
project_managerboolean column set to TRUE*.<br /> Short of using the new serializable transaction isolation level in<br
/>all related transactions, hand-coding enforcement of this useful<br /> invariant through trigger code (or application
codeenforced through<br /> some framework) is very tricky.  The change to SELECT FOR UPDATE<br /> that Florian was
workingon would make it pretty straightforward.<span class="HOEnZb"><font color="#888888"><br
/></font></span></blockquote></div><br/>I'm not sure what Florian's patch does, but I've been trying to advocate syntax
likethe following for this exact scenario:<br /><br />foreign key (manager_id, true) references person (id,
is_manager)<br/><br />Basically, allow us to use constants instead of field names as part of foreign keys.  I have no
ideawhat the implementation aspect of this is, but I need the user aspect of it and don't know the best way to get
it.<br/><br />