Trigger changes visibility

Started by amoratiabout 21 years ago2 messagesbugs
Jump to latest
#1amorati
antonio.cosas@terra.es

Hello,

I'm having an unexpected behaviour when executing an 'after delete' trigger.

In PostgreSQL 8.0.0beta5 documentation, section 33.2 "Visibility of Data
Changes", it is said that "When a row-level after trigger is fired, all
data changes made by the outer command are already complete, and are
visible to the invoked trigger function".

In my case, when executing a DELETE sql statement, the next trigger is
executed:

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

CREATE OR REPLACE FUNCTION "public"."DisparadorHijoBorradoCMin1" ()
RETURNS trigger AS
$body$
DECLARE
temporal INTEGER;

BEGIN

SELECT INTO temporal count(*) FROM "Hijo" WHERE
"Hijo"."IDPadre"=OLD."IDPadre" AND "Hijo"."IDHijo"!=OLD."IDHijo";
RAISE NOTICE 'number of Rows: %', temporal;

IF temporal < 1 THEN
RAISE EXCEPTION 'ERROR DE BORRADO';
RETURN NULL;
END IF;

RETURN NULL;
END
$body$
LANGUAGE 'plpgsql' IMMUTABLE CALLED ON NULL INPUT SECURITY INVOKER;

CREATE TRIGGER "BorradoCMin1" AFTER DELETE
ON "public"."Hijo" FOR EACH ROW
EXECUTE PROCEDURE "public"."DisparadorHijoBorradoCMin1"();

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

The problem is that the row's count done by the trigger is the same
number of rows that appears in the table before de delete was executed.
There was no other user trigger in the database.

I've send the database script attached to this mail.

Thanks in advance.

Antonio

Attachments:

PostgreSQL 8 problem.sqltext/plain; name="PostgreSQL 8 problem.sql"Download
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: amorati (#1)
Re: Trigger changes visibility

amorati <antonio.cosas@terra.es> writes:

CREATE OR REPLACE FUNCTION "public"."DisparadorHijoBorradoCMin1" ()
RETURNS trigger AS
...
LANGUAGE 'plpgsql' IMMUTABLE CALLED ON NULL INPUT SECURITY INVOKER;

The problem is that the row's count done by the trigger is the same
number of rows that appears in the table before de delete was executed.

Don't use an IMMUTABLE function as a trigger. I'm not sure if the
system should actually prohibit this, but the function is doing what
it's spec'd to, namely not seeing any side-effects of the calling query.
See
http://developer.postgresql.org/docs/postgres/xfunc-volatility.html

regards, tom lane