Re: Multiple Rules :: Postgres Is confused !! - Mailing list pgsql-general

From Najib Abi Fadel
Subject Re: Multiple Rules :: Postgres Is confused !!
Date
Msg-id 00ac01c4a61f$f7f5e1e0$f664a8c0@najib
Whole thread Raw
In response to Multiple Rules :: Postgres Is confused !!  ("Najib Abi Fadel" <nabifadel@usj.edu.lb>)
Responses Re: Multiple Rules :: Postgres Is confused !!  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Multiple Rules :: Postgres Is confused !!  (Richard Huxton <dev@archonet.com>)
List pgsql-general

> This means upd1 is redundant since any rows affected by upd1 *must* be
> affected by upd2.
OK

> > CREATE RULE transactions_sco_up8 AS ON
> >  UPDATE TO transactions_sco_v DO INSTEAD UPDATE transactions_sco SET
traiter
> > = new.traiter WHERE
> >  (transactions_sco.id = old.id);
>
> OK, this one just compares "id", which is presumably the primary key and
> unique.
Right "id" is the primary key


> > Now look what is happening:
> >
> > SELECT count(1) from transactions_sco where traiter='f';
> > count
> > -------
> >  17591
> >
> > update transactions_sco_v set traiter='t' where id = 53597;
> > UPDATE 1
> >
> > SELECT count(1) from transactions_sco where traiter='f';
> >  count
> > -------
> >  17589
> >
> > AS YOU CAN SEE TWO ROWS WHERE UPDATED INSTEAD OF ONE !!
> > THE COMMON THINGS BETWEEN THE TWO ROWS  IS THAT THE FIELDS: cod_etu,
> > cursus_id,vers_id,code_type_academic  are the same
>
> Because that's what you asked upd1/2 to do for you. To see what is
> happening, try selecting row id=53597 then manually running each rule
> yourself, substituting in the OLD.foo from your selected row. You should
> find that there are two rows that match 53597 on (cursus_id, vers_id,
> traiter, code_type_academic) - itself and one other.

Sorry, I didn't understand the manuel test procedure

What is happening here? I am doing an update and the condition is on the ID
and it is corresponding to the last Rule so why should the other rules
interfer.

Thanx for your help
Najib.





pgsql-general by date:

Previous
From: Shridhar Daithankar
Date:
Subject: Re: About PostgreSQL's limit on arithmetic operations
Next
From: Martijn van Oosterhout
Date:
Subject: Re: About PostgreSQL's limit on arithmetic operations