Re: [PATCH] SQL assertions prototype - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: [PATCH] SQL assertions prototype
Date
Msg-id 52B21116.9070501@agliodbs.com
Whole thread Raw
In response to Re: [PATCH] SQL assertions prototype  (Josh Berkus <josh@agliodbs.com>)
Responses Re: [PATCH] SQL assertions prototype
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCH] SQL assertions prototype
Next
From: Marko Tiikkaja
Date:
Subject: Re: array_length(anyarray)