Skip site navigation (1) Skip section navigation (2)

Sequence of SQL command execution involving triggers and stored procedures.

From: "Omkar Rath" <orath(at)cisco(dot)com>
To: <pgsql-sql(at)postgresql(dot)org>
Subject: Sequence of SQL command execution involving triggers and stored procedures.
Date: 2004-09-18 04:54:24
Message-ID: F67EB38120F7BB4BB972C7860958020704E5747F@ipcbu-exchange.amer.unity.cisco.com (view raw or flat)
Thread:
Lists: pgsql-sql
I am observing the following:
 
Say there is a stored procedure i.e FUNCTION sp_foo(...) which has say,
SQL commands (any of SELECT,INSERT,UPDATE,DELETE) in its body, say S1
followed by S2 then S3.... Furthermore, execution of statement S2
results in trigger functions getting invoked (that contain yet other SQL
statements).
 
By the time, the trigger functions execute (as a result of S2), S3 has
already executed.
 
Note that sp_foo() was invoked via a SELECT i.e SELECT sp_foo(...).
 
To work around this "behaviour", I wrapped sp_foo() within another
FUNCTION say sp_foo_wrapper(...) and in the body of sp_foo_wrapper() I
did this -
 
1. INSERT <something> in a scratch table // akin to setting a flag
2. Invoke sp_foo().
3. DELETE <something> from the scratch table // akin to resetting the
flag
 
Even then, by the time the triggers fired as a result of S2 (in the body
of sp_foo), the DELETE (in step 3 above) had executed.
 
Questions:
1. Did I miss something very basic?
 
2. Is this behavior random i.e the manifestation pertians to the
particular SQL commands in my code?
 
3. How does one achieve, the chronolgy that I want i.e I want S3 AND/OR
step 3 to occur AFTER the triggers (as a result of S2) to fire?
 
Thanx in advance,
 
 
 
Omkar Rath
Software Engr.
VTG
Cisco Systems Inc.

Responses

pgsql-sql by date

Next:From: Greg StarkDate: 2004-09-18 15:39:01
Subject: Re: 1-byte integers
Previous:From: stig eriksonDate: 2004-09-17 21:40:45
Subject: 1-byte integers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group