Re: Why cannot alter a column's type when it's used by a generated column - Mailing list pgsql-hackers

From jian he
Subject Re: Why cannot alter a column's type when it's used by a generated column
Date
Msg-id CACJufxHCji+0q5-Wf3B8QD-Pm8LH_D6LAoptrHxFZBK20Rk5Jw@mail.gmail.com
Whole thread Raw
In response to Re: Why cannot alter a column's type when it's used by a generated column  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
On Tue, Oct 21, 2025 at 3:56 PM Chao Li <li.evan.chao@gmail.com> wrote:

> > On Oct 21, 2025, at 15:30, jian he <jian.universality@gmail.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:
>

Sorry for the noise, I misunderstood something.
I think I understand what your patch does now.

I’ll polish my patch and submit it in a new thread.



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls
Next
From: Josh Curtis
Date:
Subject: Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin