So,
I can make all the changes I want within a transaction, and no related triggers fire before
the changes are are committed, right?
The triggers work on the image of the data before the transaction is BEGINs,
PLUS what it would look like with ALL UPDATES/DELETES in the tranaction being successfull?
And there's now way to tell which triggers on what tables affected in the transaction will
fire first, right?
2/25/2003 1:15:09 PM, Eric B.Ridge <ebr@tcdi.com> wrote:
>On Tuesday, February 25, 2003, at 03:17 PM, Dennis Gearon wrote:
>
>> are 'before' triggers or 'after' triggers more common?
>
>it depends on what you want to do. In many situations you'll need both.
>
>>
>> Why?
>
>Before triggers are most useful when you need to change the value of a
>column *before* it is updated/inserted (using the NEW table). Or if
>you want to completely deny the operation (by RETURNing NULL from the
>trigger function).
>
>After triggers are useful when you need to modify table B based on the
>fact that something successfully happened in table A. You can
>guarantee that the after triggers only happen if the before trigger and
>the actual action successfully completed.
>
>>
>> What's the benefits, problems with each?
>>
>> Can a function in a trigger lock a table? Or is it just sessions that
>> can lock a table?
>
>Yes, they can lock tables.
>
>eric
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>