Re: Unexpected behavior - Mailing list pgsql-general

From Steve V
Subject Re: Unexpected behavior
Date
Msg-id 58cabeec0605021011y4bd3c10aude74cfb3b94d5ec1@mail.gmail.com
Whole thread Raw
In response to Unexpected behavior  (Strobhen <strobhen@gmail.com>)
Responses Re: Unexpected behavior  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
On 4/27/06, Strobhen <strobhen@gmail.com> wrote:
> Hey,
>
> I am trying to figure out some unexpected behavior in Postgresql.
>
> When I create a rule that fires on a table after an update, and if
> that rule has a SELECT statement in it, it seems to be attempting to
> fire (on an empty set) regardless of how the conditional evaluates
> after an update.
>
> The result being that if I run an update on a table with such a rule,
> instead of getting a message along the lines of "UPDATE (# of rows)" I
> get the column names of the select statement with no rows and the
> message "row number -1 is out of range 0..-1".
>
> So first off, is having a select statement (I'm actually trying to run
> a function) inside a rule that fires on an update considered bad
> practice? I could do this through a trigger, but a rule just seems
> more natural.

<snip>

> 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

Thanks,
Steve

pgsql-general by date:

Previous
From: Ottavio Campana
Date:
Subject: libpq for palm?
Next
From: Martijn van Oosterhout
Date:
Subject: Re: PG_RETURN_?