Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"David G. Johnston" <david.g.johnston@xxxxxxxxx> writes:
> On Thursday, April 13, 2023, Ciprian Craciun <ciprian.craciun@xxxxxxxxx>
> 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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux