Re: Problems with RULE - Mailing list pgsql-sql

From Richard Huxton
Subject Re: Problems with RULE
Date
Msg-id 006701c0a6ec$3a60f7e0$1001a8c0@archonet.com
Whole thread Raw
In response to AW: Problems with RULE  ("Jens Hartwig" <jens.hartwig@t-systems.de>)
Responses AW: Problems with RULE  ("Jens Hartwig" <jens.hartwig@t-systems.de>)
List 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 by date:

Previous
From: Karel Zak
Date:
Subject: Re: No Documentation for to_char(INTERVAL, mask)
Next
From: "Grigoriy G. Vovk"
Date:
Subject: Re: Quick question MySQL --> PgSQL