Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1257795350.28325.24.camel@monkey-cat.sm.truviso.com обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
On Mon, 2009-11-09 at 18:03 +0000, Greg Stark wrote: > Out of curiosity, is this feature at all similar to SQL assertions? > What would we be missing to turn this into them? I addressed that here: http://archives.postgresql.org/pgsql-hackers/2009-11/msg00049.php The exclusion constraint mechanism can enforce a subset of the constraints that ASSERT can express; although the same goes for all other constraints, because ASSERT is very general. The exclusion constraint mechanism requires finding the physical tuples that cause a conflict, so that we know when to wait and on which transaction to wait. Otherwise, we have to wait on all transactions; i.e. serialize. The problem with ASSERT is that it expresses a constraint based on a query, which can return arbitrary logical records after an arbitrary amount of manipulation. So there's no way to work backwards. If we try, we'll end up either:(a) supporting only a tiny subset, and throwing bizarre errors that users don't understand when they try to work outside the template; or(b) deciding to serialize when we can't do better, andagain, users will be confused about the performance and locking characteristics. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: