From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Steve V <dndlists(at)gmail(dot)com> |
Cc: | Strobhen <strobhen(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Unexpected behavior |
Date: | 2006-05-02 17:53:18 |
Message-ID: | 20060502175318.GC13702@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, May 02, 2006 at 12:11:34PM -0500, Steve V wrote:
> >When that rule should never fire (the id hasn't changed). If I change
> >the conditional of the rule to something that must always be false
> >(like false, or 1 = 0), it will still behave in this manner.
>
> Does anyone know what's going on here? I'm experiencing an identical
> situation, and it doesn't seem logical. If it evaluates to false, why
> on earth is the function result set attempting to be returned? Maybe
> not a bug, but definitely unexpected behavior
A rule is a macro. This means that the expression in the rule will
always happen. If you have a rule to do a SELECT after an UPDATE, the
client will see the results of the SELECT.
You almost never want RULEs. It's not clear what you want to do, but a
trigger is more likely to do what you want (as well as a lot easier to
understand).
If you set debug_print_rewritten=on you should be able to see what is
actually being executed...
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2006-05-02 17:55:05 | Re: Using a pointer as statetype for an aggregate |
Previous Message | Martijn van Oosterhout | 2006-05-02 17:46:58 | Re: PG_RETURN_? |