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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers