Thread: BUG #1953: trigger action on delete
The following bug has been logged online:
Bug reference: 1953
Logged by: incheol yang
Email address: zoar@paran.com
PostgreSQL version: 8.0.4
Operating system: fedora core 4
Description: trigger action on delete
Details:
kernel version 2.6.13-1.1526_FC4
CPU AMD ATHLON 1G Hz
kernel version 2.6.13-1.1526_FC4
rpm postgresql-8.0.4-2.FC4.1
db encoded by UNICODE
_int.sql contrib was appended
source code was copied by mouse.
cc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
cc -fpic -c trigf.c -I/usr/include/pgsql/server
cc -shared -o trigf.so trigf.o
===============================================================
8.0.4 Document chapter 32.4
===============================================================
INSERT, INSERT INTO, UPDATE commands had same output, but
=> DELETE FROM ttest;
INFO: trigf (fired before): there are 2 rows in ttest
INFO: trigf (fired after ): there are 1 rows in ttest
INFO: trigf (fired before): there are 1 rows in ttest
INFO: trigf (fired after ): there are 0 rows in ttest
^^^^^^
fired before -> after -> before -> after
===============================================================
My output
===============================================================
=> DELETE FROM ttest;
INFO: trigf (fired before): there are 2 rows in ttest
INFO: trigf (fired before): there are 1 rows in ttest
INFO: trigf (fired after ): there are 0 rows in ttest
INFO: trigf (fired after ): there are 0 rows in ttest
fired before -> before -> after -> after
Is this my fault?
~
Sorry, I can not understand what you were testing here. --------------------------------------------------------------------------- incheol yang wrote: > > The following bug has been logged online: > > Bug reference: 1953 > Logged by: incheol yang > Email address: zoar@paran.com > PostgreSQL version: 8.0.4 > Operating system: fedora core 4 > Description: trigger action on delete > Details: > > kernel version 2.6.13-1.1526_FC4 > > CPU AMD ATHLON 1G Hz > kernel version 2.6.13-1.1526_FC4 > > rpm postgresql-8.0.4-2.FC4.1 > > db encoded by UNICODE > > _int.sql contrib was appended > > source code was copied by mouse. > > cc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) > > cc -fpic -c trigf.c -I/usr/include/pgsql/server > cc -shared -o trigf.so trigf.o > > =============================================================== > 8.0.4 Document chapter 32.4 > =============================================================== > > INSERT, INSERT INTO, UPDATE commands had same output, but > > > => DELETE FROM ttest; > INFO: trigf (fired before): there are 2 rows in ttest > INFO: trigf (fired after ): there are 1 rows in ttest > INFO: trigf (fired before): there are 1 rows in ttest > INFO: trigf (fired after ): there are 0 rows in ttest > ^^^^^^ > fired before -> after -> before -> after > > =============================================================== > My output > =============================================================== > > => DELETE FROM ttest; > INFO: trigf (fired before): there are 2 rows in ttest > INFO: trigf (fired before): there are 1 rows in ttest > INFO: trigf (fired after ): there are 0 rows in ttest > INFO: trigf (fired after ): there are 0 rows in ttest > > fired before -> before -> after -> after > > > Is this my fault? > > ~ > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > > Sorry, I can not understand what you were testing here. I see now. I am running some tests to try to reproduce it. --------------------------------------------------------------------------- > > --------------------------------------------------------------------------- > > incheol yang wrote: > > > > The following bug has been logged online: > > > > Bug reference: 1953 > > Logged by: incheol yang > > Email address: zoar@paran.com > > PostgreSQL version: 8.0.4 > > Operating system: fedora core 4 > > Description: trigger action on delete > > Details: > > > > kernel version 2.6.13-1.1526_FC4 > > > > CPU AMD ATHLON 1G Hz > > kernel version 2.6.13-1.1526_FC4 > > > > rpm postgresql-8.0.4-2.FC4.1 > > > > db encoded by UNICODE > > > > _int.sql contrib was appended > > > > source code was copied by mouse. > > > > cc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) > > > > cc -fpic -c trigf.c -I/usr/include/pgsql/server > > cc -shared -o trigf.so trigf.o > > > > =============================================================== > > 8.0.4 Document chapter 32.4 > > =============================================================== > > > > INSERT, INSERT INTO, UPDATE commands had same output, but > > > > > > => DELETE FROM ttest; > > INFO: trigf (fired before): there are 2 rows in ttest > > INFO: trigf (fired after ): there are 1 rows in ttest > > INFO: trigf (fired before): there are 1 rows in ttest > > INFO: trigf (fired after ): there are 0 rows in ttest > > ^^^^^^ > > fired before -> after -> before -> after > > > > =============================================================== > > My output > > =============================================================== > > > > => DELETE FROM ttest; > > INFO: trigf (fired before): there are 2 rows in ttest > > INFO: trigf (fired before): there are 1 rows in ttest > > INFO: trigf (fired after ): there are 0 rows in ttest > > INFO: trigf (fired after ): there are 0 rows in ttest > > > > fired before -> before -> after -> after > > > > > > Is this my fault? > > > > ~ > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: Don't 'kill -9' the postmaster > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On 10/11/05, incheol yang <zoar@paran.com> wrote: > > The following bug has been logged online: > > Bug reference: 1953 > Logged by: incheol yang > Email address: zoar@paran.com > PostgreSQL version: 8.0.4 > Operating system: fedora core 4 > Description: trigger action on delete > Details: > > kernel version 2.6.13-1.1526_FC4 > > CPU AMD ATHLON 1G Hz > kernel version 2.6.13-1.1526_FC4 > > rpm postgresql-8.0.4-2.FC4.1 > > db encoded by UNICODE > > _int.sql contrib was appended > > source code was copied by mouse. > > cc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) > > cc -fpic -c trigf.c -I/usr/include/pgsql/server > cc -shared -o trigf.so trigf.o > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 8.0.4 Document chapter 32.4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > INSERT, INSERT INTO, UPDATE commands had same output, but > > > =3D> DELETE FROM ttest; > INFO: trigf (fired before): there are 2 rows in ttest > INFO: trigf (fired after ): there are 1 rows in ttest > INFO: trigf (fired before): there are 1 rows in ttest > INFO: trigf (fired after ): there are 0 rows in ttest > ^^^^^^ > fired before -> after -> before -> after > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > My output > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D> DELETE FROM ttest; > INFO: trigf (fired before): there are 2 rows in ttest > INFO: trigf (fired before): there are 1 rows in ttest > INFO: trigf (fired after ): there are 0 rows in ttest > INFO: trigf (fired after ): there are 0 rows in ttest > > fired before -> before -> after -> after > > > Is this my fault? > The triggers are fired in alphabetical order, check the names of the trigge= rs... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;)
> The triggers are fired in alphabetical order, check the names of the triggers... It isn't so much the alphabetical order, since there is only one trigger, but the concept that we now group all the _before_ triggers before the _after_ triggers. I have updated the sample output to reflect our new trigger fire ordering. Thanks for the report. --------------------------------------------------------------------------- Jaime Casanova wrote: > On 10/11/05, incheol yang <zoar@paran.com> wrote: > > > > The following bug has been logged online: > > > > Bug reference: 1953 > > Logged by: incheol yang > > Email address: zoar@paran.com > > PostgreSQL version: 8.0.4 > > Operating system: fedora core 4 > > Description: trigger action on delete > > Details: > > > > kernel version 2.6.13-1.1526_FC4 > > > > CPU AMD ATHLON 1G Hz > > kernel version 2.6.13-1.1526_FC4 > > > > rpm postgresql-8.0.4-2.FC4.1 > > > > db encoded by UNICODE > > > > _int.sql contrib was appended > > > > source code was copied by mouse. > > > > cc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) > > > > cc -fpic -c trigf.c -I/usr/include/pgsql/server > > cc -shared -o trigf.so trigf.o > > > > =============================================================== > > 8.0.4 Document chapter 32.4 > > =============================================================== > > > > INSERT, INSERT INTO, UPDATE commands had same output, but > > > > > > => DELETE FROM ttest; > > INFO: trigf (fired before): there are 2 rows in ttest > > INFO: trigf (fired after ): there are 1 rows in ttest > > INFO: trigf (fired before): there are 1 rows in ttest > > INFO: trigf (fired after ): there are 0 rows in ttest > > ^^^^^^ > > fired before -> after -> before -> after > > > > =============================================================== > > My output > > =============================================================== > > > > => DELETE FROM ttest; > > INFO: trigf (fired before): there are 2 rows in ttest > > INFO: trigf (fired before): there are 1 rows in ttest > > INFO: trigf (fired after ): there are 0 rows in ttest > > INFO: trigf (fired after ): there are 0 rows in ttest > > > > fired before -> before -> after -> after > > > > > > Is this my fault? > > > > > -- > regards, > Jaime Casanova > (DBA: DataBase Aniquilator ;) > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> It isn't so much the alphabetical order, since there is only one
> trigger, but the concept that we now group all the _before_ triggers
> before the _after_ triggers.
But we've always done that. Has the example ever been correct?
I was intending to try it on older versions, but I don't actually
think it's ever acted like the docs said.
regards, tom lane
I wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> It isn't so much the alphabetical order, since there is only one
>> trigger, but the concept that we now group all the _before_ triggers
>> before the _after_ triggers.
> But we've always done that. Has the example ever been correct?
> I was intending to try it on older versions, but I don't actually
> think it's ever acted like the docs said.
After digging in the CVS archives, I find that it did work like that
up till this 7.0 patch:
1999-09-29 12:05 wieck
This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support.
Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS
commands.
So the example was probably correct when put in, but no one's noticed it
was wrong since 7.0 :-(
regards, tom lane
On 10/12/2005 11:20 PM, Tom Lane wrote: > I wrote: >> Bruce Momjian <pgman@candle.pha.pa.us> writes: >>> It isn't so much the alphabetical order, since there is only one >>> trigger, but the concept that we now group all the _before_ triggers >>> before the _after_ triggers. > >> But we've always done that. Has the example ever been correct? >> I was intending to try it on older versions, but I don't actually >> think it's ever acted like the docs said. > > After digging in the CVS archives, I find that it did work like that > up till this 7.0 patch: > > 1999-09-29 12:05 wieck > > This is part #1 for of the DEFERRED CONSTRAINT TRIGGER support. > Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS > commands. > > So the example was probably correct when put in, but no one's noticed it > was wrong since 7.0 :-( IIRC we had discussed that stuff during the RI development and decided to have ALL _after_ triggers get fired by the deferred queue after the statement. The example deletes multiple rows in one statement. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #