Re: Problems with RULE
От | Richard Huxton |
---|---|
Тема | Re: Problems with RULE |
Дата | |
Msg-id | 006701c0a6ec$3a60f7e0$1001a8c0@archonet.com обсуждение исходный текст |
Ответ на | AW: Problems with RULE ("Jens Hartwig" <jens.hartwig@t-systems.de>) |
Ответы |
AW: Problems with RULE
|
Список | pgsql-sql |
From: "Jens Hartwig" <jens.hartwig@t-systems.de> > Hello Richard, > > this was a very precise analysis - thanks for the effort you made! Precisely wrong in this case. My mistakes have some of the finest tolerances in the world. 8-) > Nevertheless the Tom's explanation of the behaviour in case of views was > sufficient for me. But still I don't understand the behaviour in my case ... Yep - thanks Tom (another item for my notebook). I _think_ I understand Tom's explanation of your case - does this make sense? You have CREATE RULE r1 ON t_xyz WHERE old.deleted=false ... So - if you issue "DELETE FROM t_xyz" you'd want two things to happen: 1. where deleted is false set it to true 2. where deleted was true delete the record So - PG rewrites the query into two parts: DELETE FROM t_xyz WHERE old.deleted=false DELETE FROM t_xyz WHERE NOT(old.deleted=false) Unfortunately, the changes from the first part are visible to the second part so you end up marking everything for deletion then deleting it. Of course in your case you were selecting id=1 so it wasn't so obvious. I think that's what's happening here. Unfortunately, setting DEBUG_PRINT_xxx doesn't seem to show any detail, do I can't show a trace. Of course, with a trigger you can have an IF..THEN..ELSE to make sure you control the order of execution. - Richard Huxton
В списке pgsql-sql по дате отправления: