Re: [GENERAL] Trigger Firing Order

2013-12-11 Thread Sameer Kumar
But with certain packaged products who create their own triggers, I won't have control over this. I don't have a lot of sympathy for that argument. If the product is capable of creating Postgres-compatible triggers at all, it should be aware that the name is a significant property, and

Re: [GENERAL] Trigger Firing Order

2013-12-11 Thread Kevin Grittner
Sameer Kumar sameer.ku...@ashnik.com wrote: If I have a trigger which add primary key to my inserted row (before trigger). Now if I plan to create new set of triggers for AUDITING or replication (where either I have no flexibility of choosing a name or the trigger name has to follow a

Re: [GENERAL] Trigger Firing Order

2013-12-11 Thread Sameer Kumar
That sounds like a nice suggestion. I guess it could get rid of most of the issues I forsee. I should follow that for my cases too. I guess we can live without an ORDER clause. Thanks everyone for helping.

[GENERAL] Trigger Firing Order

2013-12-10 Thread Sameer Kumar
Hi, Is it possible for me to define the order in which triggers will be fired? So far what I have understood from PostgreSQL documentation, in order to fire 2 triggers in sequence (say trigger1 and trigger2) on a table, I need to name them in that way. But with certain packaged products who

Re: [GENERAL] Trigger Firing Order

2013-12-10 Thread David Johnston
Sameer Kumar wrote Hi, Is it possible for me to define the order in which triggers will be fired? So far what I have understood from PostgreSQL documentation, in order to fire 2 triggers in sequence (say trigger1 and trigger2) on a table, I need to name them in that way. But with certain

Re: [GENERAL] Trigger Firing Order

2013-12-10 Thread Tom Lane
Sameer Kumar sameer.ku...@ashnik.com writes: Is it possible for me to define the order in which triggers will be fired? Sure: choose their names so that their alphabetical ordering is the firing order you want. But I see you knew that. But with certain packaged products who create their own

Re: [GENERAL] trigger firing order

2006-04-11 Thread Alban Hertroys
Hugo wrote: Hi, how can I tell in which order are triggered different triggers on the same table, let me explain , I have three triggers for table A, all of then are intended for before insert on the table, in ASA I can tell the Db in which order I want the triggers to fire, is there an

[GENERAL] trigger firing order

2006-04-10 Thread Hugo
Hi, how can I tell in which order are triggered different triggers on the same table, let me explain , I have three triggers for table A, all of then are intended for before insert on the table, in ASA I can tell the Db in which order I want the triggers to fire, is there an equivalent for

Re: [GENERAL] trigger firing order

2006-04-10 Thread Richard Broersma Jr
Hi, how can I tell in which order are triggered different triggers on the same table, let me explain , I have three triggers for table A, all of then are intended for before insert on the table, in ASA I can tell the Db in which order I want the triggers to fire, is there an equivalent for

Re: [GENERAL] trigger firing order

2006-04-10 Thread Terry Lee Tucker
On Monday 10 April 2006 05:09 pm, Hugo saith: Hi, how can I tell in which order are triggered different triggers on the same table, let me explain , I have three triggers for table A, all of then are intended for before insert on the table, in ASA I can tell the Db in which order I want the

Re: [GENERAL] trigger firing order

2006-04-10 Thread Geoffrey
Terry Lee Tucker wrote: On Monday 10 April 2006 05:09 pm, Hugo saith: Hi, how can I tell in which order are triggered different triggers on the same table, let me explain , I have three triggers for table A, all of then are intended for before insert on the table, in ASA I can tell the Db in

Re: [GENERAL] Trigger firing order

2000-11-29 Thread Tom Lane
"Alex Bolenok" [EMAIL PROTECTED] writes: peroon=# INSERT INTO t_foo (foo_value) VALUES (2000); NOTICE: fn_foo_ains: Start NOTICE: fn_foo_ains: End NOTICE: fn_bar_ains: Start NOTICE: fn_bar_ains: End Looking at the code, it seems that all AFTER triggers are implicitly handled as DEFERRED