On 12/18/2013 11:26 AM, Jim Nasby wrote:
> The flip-side is that now you can get serialization failures, and I
> think there's a ton of software that has no clue how to deal with that.
> So now you don't get to use assertions at all unless you re-engineer
> your application (but see below).
Well, the software will need to deal with an Assertion failure, which I
doubt it's prepared to do right now either.
>> This is consistent with how we treat the interaction of constraints and
>> triggers; under some circumstances, we allow triggers to violate CHECK
>> and FK constraints.
>
> We do? Under what circumstances?
AFTER triggers are allowed to ignore constraints sometimes. For
example, if you have a tree table with an FK to other rows in the same
table, and you have an AFTER trigger on it, the AFTER trigger is allowed
to violate the self-FK. That's the one I ran across, but I vaguely
remember other cases, and there's some documentation on this in the
order of application of triggers in the main docs.
> Another possibility is to allow for two different types of assertions,
> one based on SSI and one based on locking.
The locking version would have to pretty much lock on a table basis (or
even a whole-database basis) every time an assertion executed, no?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
