Thread: BUG #1955: trigger action on delete

BUG #1955: trigger action on delete

From
"incheol yang"
Date:
The following bug has been logged online:

Bug reference:      1955
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

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

cp trigf.so /usr/lib/pgsql/.

===============================================================

       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?

Re: BUG #1955: trigger action on delete

From
Tom Lane
Date:
"incheol yang" <zoar@paran.com> writes:
> => 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?

I think this is a documentation bug.  I'm not sure the example output
was ever correct, but it's certainly wrong now.

            regards, tom lane