Re: Problems with RULE

From: "Richard Huxton" <dev(at)archonet(dot)com>
To: "Jens Hartwig" <jens(dot)hartwig(at)t-systems(dot)de>
Cc: "'PSQL-Sql (E-Mail)'" <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Problems with RULE
Date: 2001-03-07 09:50:26
Message-ID: 006701c0a6ec$3a60f7e0$1001a8c0@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

From: "Jens Hartwig" <jens(dot)hartwig(at)t-systems(dot)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

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Emils Klotins 2001-03-07 10:01:30 default value syntax - pg compared to?
Previous Message Karel Zak 2001-03-07 08:48:49 Re: [SQL] Re: Re: MySQLs Describe emulator!