Re: Unexpected behavior when combining `generated always` columns and update rules - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Unexpected behavior when combining `generated always` columns and update rules
Date
Msg-id 610e53b5-aba2-d232-9448-765327b88431@aklaver.com
Whole thread Raw
In response to Re: Unexpected behavior when combining `generated always` columns and update rules  (Ciprian Craciun <ciprian.craciun@gmail.com>)
Responses Re: Unexpected behavior when combining `generated always` columns and update rules
List pgsql-general
On 4/13/23 09:27, Ciprian Craciun wrote:
> On Thu, Apr 13, 2023 at 5:32 PM David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> ALSO rules behave like before triggers, not after triggers. The original command is appended to the end of the list
ofcommands, 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.

Just realized we may have both being saying the same thing. That your 
'...actually computed on insertion,...' meant not just for an INSERT but 
for any change in the data. In other words when the original query 
actually ran.

> 
> Ciprian.
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Unexpected behavior when combining `generated always` columns and update rules
Next
From: Tom Lane
Date:
Subject: Re: Unexpected behavior when combining `generated always` columns and update rules