Re: Unexpected behavior

Поиск
Список
Период
Сортировка
От Steve V
Тема Re: Unexpected behavior
Дата
Msg-id 58cabeec0605021011y4bd3c10aude74cfb3b94d5ec1@mail.gmail.com
обсуждение исходный текст
Ответ на Unexpected behavior  (Strobhen <strobhen@gmail.com>)
Ответы Re: Unexpected behavior  (Martijn van Oosterhout <kleptog@svana.org>)
Список 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 по дате отправления:

Предыдущее
От: Ottavio Campana
Дата:
Сообщение: libpq for palm?
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: PG_RETURN_?