Re: Unexpected behavior when combining `generated always` columns and update rules

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unexpected behavior when combining `generated always` columns and update rules
Дата
Msg-id 1332832.1681396660@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Unexpected behavior when combining `generated always` columns and update rules  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thursday, April 13, 2023, Ciprian Craciun <ciprian.craciun@gmail.com>
> wrote:
>> create or replace rule propagate_x_and_d as on update to x do also
>> update y set x = new.x, d = new.d where y.x = old.x;
>> 
>> As seen above, although the rule correctly propagates the change to
>> the `x` column, it fails to use the new value for the `d` column, but
>> instead uses the previous one.

> ALSO rules behave like before triggers, not after triggers. The original
> command is appended to the end of the list of commands, not the start.

It depends actually ... per [1],

    For ON INSERT rules, the original query (if not suppressed by INSTEAD)
    is done before any actions added by rules. This allows the actions to
    see the inserted row(s). But for ON UPDATE and ON DELETE rules, the
    original query is done after the actions added by rules. This ensures
    that the actions can see the to-be-updated or to-be-deleted rows;
    otherwise, the actions might do nothing because they find no rows
    matching their qualifications.

            regards, tom lane

[1] https://www.postgresql.org/docs/current/rules-update.html



В списке pgsql-general по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Unexpected behavior when combining `generated always` columns and update rules
Следующее
От: Sebastien Flaesch
Дата:
Сообщение: JSON / ASP.NET AJAX Dates support in PostgreSQL