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  ("Jens Hartwig" <jens.hartwig@t-systems.de>)
Список 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 по дате отправления:

Предыдущее
От: Karel Zak
Дата:
Сообщение: Re: No Documentation for to_char(INTERVAL, mask)
Следующее
От: "Grigoriy G. Vovk"
Дата:
Сообщение: Re: Quick question MySQL --> PgSQL