Re: Avoiding cycles in a directed graph
От | Richard Huxton |
---|---|
Тема | Re: Avoiding cycles in a directed graph |
Дата | |
Msg-id | 4BA002DC.1050700@archonet.com обсуждение исходный текст |
Ответ на | Re: Avoiding cycles in a directed graph (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Avoiding cycles in a directed graph
|
Список | pgsql-sql |
On 16/03/10 21:09, Tom Lane wrote: > Tony Cebzanov<tonyceb@andrew.cmu.edu> writes: >> I'm okay with running the big, fat WITH RECURSIVE query in my insert >> trigger if I have to -- it won't be great for performance, but I don't >> expect this to be a frequent operation, so I'll accept the performance >> hit if it works. > >> Unfortunately I can't even get that working. Here's the (not at all >> functional) trigger I've got right now, which only detects the cycle >> *after* it's been inserted, which is of no help at all. Any way I can >> modify this to do the right thing? > > Run it in an AFTER trigger? > > If you don't expect this to be common, maybe you could fix the > concurrency issue by taking a table-wide lock that locks out > other writers. Surely SELECT FOR UPDATE on the parents would be sufficient? If there's no overlap between (currently non-cyclic) graphs being altered then there can't be any conflict. -- Richard Huxton Archonet Ltd
В списке pgsql-sql по дате отправления: