Re: Why cannot alter a column's type when it's used by a generated column

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why cannot alter a column's type when it's used by a generated column
Date: 2025-10-21 07:55:46
Message-ID: 48E5B684-273F-412C-B35D-7337A8F5A57E@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Oct 21, 2025, at 15:30, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> +-- So, you can change a column's type as long as any dependent generated
> +-- column already has a set expression defined:
> +ALTER TABLE gtest27
> + ALTER COLUMN a TYPE float8,
> + ALTER COLUMN x SET EXPRESSION AS ((a::int + b) * 2);
> +\d gtest27
> + Table "generated_stored_tests.gtest27"
> + Column | Type | Collation | Nullable |
> Default
> +--------+------------------+-----------+----------+---------------------------------------------------
> + a | double precision | | |
> + b | bigint | | |
> + x | bigint | | | generated always
> as ((a::integer + b) * 2) stored
> +
>
> the above output seems wrong?
> one way to quickly test it is create table gtest27 again

I don’t get what is wrong? Actually “make check” passed from my side:

```
% make check

1..230
# All 230 tests passed.
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-10-21 08:00:47 RE: Invalid primary_slot_name triggers warnings in all processes on reload
Previous Message Álvaro Herrera 2025-10-21 07:54:01 Re: Accessing an invalid pointer in BufferManagerRelation structure