Feedback-ID: ie0a040ee:Fastmail
Message-ID: <0aefea9d-9cab-47b5-985f-91eb4b02bb74@eisentraut.org>
Date: Wed, 8 Jan 2025 14:41:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Virtual generated columns
To: Richard Guo <guofenglinux@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
 jian he <jian.universality@gmail.com>,
 Dean Rasheed <dean.a.rasheed@gmail.com>
References: <a368248e-69e4-40be-9c07-6c3b5880b0a6@eisentraut.org>
 <CACJufxHxoz_KVQxcQ=cSvJc+PNbh=FaHbcMZCOisoOaGAgjy4w@mail.gmail.com>
 <732a9543-0312-4f0c-a471-857b507a3546@eisentraut.org>
 <ebd1e0e9-115f-4dfa-98b8-e9b8e2f9eb2d@eisentraut.org>
 <CAEZATCV=RX0M58-uqSR6tFjwQAFnEcx3hvW-9ZZfRQJLg5LzRw@mail.gmail.com>
 <0f811f71-8c86-4e1b-b3bb-6a535674a440@eisentraut.org>
 <CAEZATCU3q=znAL7X1aSxuMpjfSyB1cT5j398HPb9ix9ci_HUqA@mail.gmail.com>
 <cd7c0fea-6c4b-4bdd-af3b-4d4dabb32ca1@eisentraut.org>
 <CAEZATCVLfMzNwT1J0bnvtv6YbmNSN9QSXb+1QSGyX6vK4q67Ow@mail.gmail.com>
 <ef7c466d-e3b9-4d60-bc03-cd9b48581442@eisentraut.org>
 <09800cb1-43aa-4239-8918-46b71ede4900@eisentraut.org>
 <536b281b-2cb3-4477-971f-c64838bc6263@eisentraut.org>
 <CAEZATCUHnmOu7RtDuP+PCtS_dqvU8hFsAYYFPdiB8gyFszj5WQ@mail.gmail.com>
 <51875199-d5f5-41ed-92dc-3e7b1b996991@eisentraut.org>
 <e5075513-2a0e-4550-bf45-41942af2b676@eisentraut.org>
 <CAMbWs48Ki7vScBfO0_JD_LTFPwbS-Vi-HKqQfg8ZK34OL0APKg@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CAMbWs48Ki7vScBfO0_JD_LTFPwbS-Vi-HKqQfg8ZK34OL0APKg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/0aefea9d-9cab-47b5-985f-91eb4b02bb74%40eisentraut.org>
Precedence: bulk

On 08.01.25 09:22, Richard Guo wrote:
>> - Added support for ALTER TABLE ... SET EXPRESSION.
> When using ALTER TABLE to set expression for virtual generated
> columns, we don't enforce a rewrite, which means we don't have the
> opportunity to check whether the new values for these columns could
> cause an underflow or overflow.  For instance,
> 
> create table t (a int, b int generated always as (a) virtual);
> insert into t values (2147483647);
> 
> # alter table t alter column b set expression as (a * 2);
> ALTER TABLE
> 
> # select * from t;
> ERROR:  integer out of range
> 
> The same thing could occur with INSERT.  As we don't compute virtual
> generated columns on write, we may end up inserting values that cause
> underflow or overflow for these columns.
> 
> create table t1 (a int, b int generated always as (a * 2) virtual);
> insert into t1 values (2147483647);
> 
> # select * from t1;
> ERROR:  integer out of range
> 
> I'm not sure if this is expected or not, so I just wanted to point it
> out.

Yes, this is expected behavior.  This also happens with a view.  So it 
is consistent for compute-on-read objects.