Re: foreign key locks, 2nd attempt
От | Kevin Grittner |
---|---|
Тема | Re: foreign key locks, 2nd attempt |
Дата | |
Msg-id | 4F48CECE0200002500045BBF@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: foreign key locks, 2nd attempt (Vik Reykja <vikreykja@gmail.com>) |
Список | pgsql-hackers |
Vik Reykja <vikreykja@gmail.com> wrote: > Kevin Grittner <Kevin.Grittner@wicourts.gov>wrote: > >> One of the problems that Florian was trying to address is that >> people often have a need to enforce something with a lot of >> similarity to a foreign key, but with more subtle logic than >> declarative foreign keys support. One example would be the case >> Robert has used in some presentations, where the manager column >> in each row in a project table must contain the id of a row in a >> person table *which has the project_manager boolean column set to >> TRUE*. Short of using the new serializable transaction isolation >> level in all related transactions, hand-coding enforcement of >> this useful invariant through trigger code (or application code >> enforced through some framework) is very tricky. The change to >> SELECT FOR UPDATE that Florian was working on would make it >> pretty straightforward. > > I'm not sure what Florian's patch does, but I've been trying to > advocate syntax like the following for this exact scenario: > > foreign key (manager_id, true) references person (id, is_manager) > > Basically, allow us to use constants instead of field names as > part of foreign keys. Interesting. IMV, a declarative approach like that is almost always better than the alternatives, so something like this (possibly with different syntax) would be another step in the right direction. I suspect that there will always be a few corner cases where the business logic required is too esoteric to be handled by a generalized declarative construct, so I think Florian's idea still has merit -- especially if we want to ease the transition to PostgreSQL for large shops using other products. > I have no idea what the implementation aspect of this is, > but I need the user aspect of it and don't know the best way to > get it. There are those in the community who make their livings by helping people get the features they want. If you have some money to fund development, I would bet you could get this addressed -- it sure sounds reasonable to me. -Kevin
В списке pgsql-hackers по дате отправления: