On 11/19/2013 03:54 PM, Andres Freund wrote:
On 2013-11-19 12:45:27 -0800, Josh Berkus wrote:
On 11/19/2013 08:42 AM, Andres Freund wrote:
Could you explain a bit what the use case of this is and why it's not
sufficient to allow constraint triggers to work on a statement level?
"Just" that there would be multiple ones fired?
The main reason is to enforce arbitrary assertions which need
enforcement at the end of a transaction and not before. For example:
[...]
You can't enforce this at the statement level because the
update/insert/deletes can happen in any order on the various tables.
That's why I suggested adding statement level constraint triggers
(should be a farily small patch), which can be deferred till commit. The
problem there is that they can be triggered several times, but that can
relatively easily accounted for in user code.
I can't really say why, but commit time even triggers make me nervous...
This feature is really extremely close to being a deferred constraint
trigger that is called once. The code that calls these event triggers
runs right before the code that runs the deferred triggers. That spot in
the code was chosen with some care, to try to reduce any risk from the
feature.
Putting the onus on the user to detect multiple invocations of the
trigger would make for MORE fragility, not less.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
