Re: Unexpected behavior

From: "Steve V" <dndlists(at)gmail(dot)com>
To: Strobhen <strobhen(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Unexpected behavior
Date: 2006-05-02 17:11:34
Message-ID: 58cabeec0605021011y4bd3c10aude74cfb3b94d5ec1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 4/27/06, Strobhen <strobhen(at)gmail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-05-02 17:46:58 Re: PG_RETURN_?
Previous Message Don Y 2006-05-02 17:06:19 Re: PG_RETURN_?