SEO

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

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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?
>

The triggers are fired in alphabetical order, check the names of the triggers...

--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

> 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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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 #

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq