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]

 



On 4/13/23 09:27, Ciprian Craciun wrote:
On Thu, Apr 13, 2023 at 5:32 PM David G. Johnston
<david.g.johnston@xxxxxxxxx> wrote:
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.


As Tom observed, the documentation states that in case of update
rules, the original query is executed at the end.

However, regardless of the order of the execution between new and
original query, as per the documentation the `new` table should
contain the new values regardless.

In fact, from my example above, one can see that the `y.x` is properly
updated with the new value, meanwhile the `y.d` is the previous one
(i.e. `old.d`).

So, based on these observations, I think that `generated always`
columns are actually computed on insertion, and thus they are not
reflected in `new` on rules.

That is not the case:

create table x (x int, d int generated always as (x * 10) stored);
insert into x (x) values (1);
select * from x;

 x | d
---+----
 1 | 10

update x set x = 2 where x = 1;
select * from x;

 x | d
---+----
 2 | 20

What I believe is happening is that the generated always is not done until the original query is run after the rule action. So at the time of the rule action x.d is still 10.

What this points out is that you will lead a simpler life if you use triggers instead of rules.


Ciprian.



--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx






[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