Re: Rules aren't doing what I expect

From: Mark Volpe <volpe(dot)mark(at)epamail(dot)epa(dot)gov>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Rules aren't doing what I expect
Date: 2000-08-11 16:03:48
Message-ID: 399423E4.BECD53E5@epamail.epa.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Tom Lane wrote:
>
> Queries added by non-INSTEAD rules are always performed before the
> initially-given query, so you're right, the rule will see the unmodified
> value.
>
> I'd suggest folding the log-entry-making into your trigger, actually.
> If you have a trigger anyway then the insert into t1_log is only one
> more line in that trigger procedure...
>
> regards, tom lane

Thanks for the explanation, Tom. I left out part of my story though. :) I
would like normal users to be able to modify t1 but not t1_log, and doing what
you said would require INSERT permission on t1_log. So what I did was go ahead
and allow INSERT permission, but create before and after triggers on t1_log
that check the inserted values against reality... but that brings up another
question -

If I do an UPDATE on t1, it calls a trigger which eventually does:
INSERT INTO t1_log VALUES(OLD.a, NEW.a);

If t1_log has before and after triggers, the before trigger will always see
the old row in t1, and the after trigger will always see the new data, right?
At least that's what I'm seeing. The "visibility of data changes" document
was kinda confusing...

Mark

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Madel, Kurt 2000-08-11 17:14:42 Trying to Creat a Rule
Previous Message Tom Lane 2000-08-11 15:53:55 Re: Problem with SQL query (eats swap)