From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org>, pgsql-de-allgemein(at)postgresql(dot)org |
Subject: | Re: Trigger und Funktion |
Date: | 2007-03-08 13:24:27 |
Message-ID: | 7D902730CBFEE994AE9015A4@imhotep.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-de-allgemein |
--On Donnerstag, März 08, 2007 13:20:24 +0100 Andreas Seltenreich
<andreas+pg(at)gate450(dot)dyndns(dot)org> wrote:
> A. Kretschmer writes:
>
>> am Wed, dem 07.03.2007, um 23:05:24 +0100 mailte udono folgendes:
>>> Es soll die Regel gelten, dass nur Buchungssätze in die Tabelle
>>> acc_trans dürfen (UPDATE, INSERT), deren Summe der Einzelbeträge
>>> (amount) aller Teilbuchungen (trans_id) 0 ergibt.
>>
>>
>> IMHO wäre hier ein ON COMMIT TRIGGER sinnvoll. Haben wir leider nicht.
>
> Hm, wenn man das "It is not intended for general use" in der Doku zu
> "create constraint trigger" überliest, kann man damit scheinbar den
> gewünschten Effekt erzielen:
>
Hmm, an sich clever, aber ich sehe nicht wie man damit das
Konsistenzproblem mit mehreren gleichzeitigen Transaktionen lösen kann.
Ferner sollte man beachten, dass Deferred Trigger bei sehr großen
Transaktionen schnell ein Speicherproblem verursachen können. Um das
wirklich 'sicher' abzuwickeln kommt man um die nötige Serialisierung
mittels Peter's vorgeschlagener Methode mit expliziten Locks nicht
drumherum, fürchte ich.....
--
Thanks
Bernd
From | Date | Subject | |
---|---|---|---|
Next Message | udono | 2007-03-08 14:20:46 | Re: Trigger und Funktion |
Previous Message | Andreas Kretschmer | 2007-03-08 12:31:03 | Re: Trigger und Funktion |