Re: Virtual generated columns - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Virtual generated columns
Date
Msg-id 8e85378a-934d-41fb-b92c-737f3023d3bc@eisentraut.org
Whole thread Raw
In response to Re: Virtual generated columns  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On 11.12.24 07:49, jian he wrote:
> On Fri, Nov 29, 2024 at 6:01 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>> The purpose of check_modified_virtual_generated() for trigger functions
>> written in C.  The prevent someone from inserting real values into the
>> trigger tuples, because they would then be processed by the rest of the
>> system, which would be incorrect.
>>
>> Higher-level languages such as plpgsql should handle that themselves, by
>> preventing setting generated columns in trigger functions.  The presence
>> of check_modified_virtual_generated() is still a backstop for those, but
>> shouldn't really be necessary.
> 
> please check the attached patch.
> * remove check_modified_virtual_generated.
> * using heap_modify_tuple_by_cols in ExecBRInsertTriggers, ExecBRUpdateTriggers
> to overwrite virtual generated columns value to null.
> 
> and it's not complicated.
> so that trigger behavior for stored and virtual will be more aligned

I have integrated that into v11.  I agree it's not complicated and it's 
better to keep the behavior aligned.

I kept the function check_modified_virtual_generated() but now it just 
modifies the tuple, using your code, instead of erroring.  That avoids 
having to write the same code twice.

I don't understand the purpose of the change in pl_exec.c.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Virtual generated columns
Next
From: Peter Eisentraut
Date:
Subject: Re: Virtual generated columns