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

From Chao Li
Subject Re: Why cannot alter a column's type when it's used by a generated column
Date
Msg-id CAEoWx2ntXwiAS8-gknV32uosSKPsS7gXKwT7T3ijqKyWWoMkJw@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  (jian he <jian.universality@gmail.com>)
Responses Re: Why cannot alter a column's type when it's used by a generated column
List pgsql-hackers
Hi Jian,

Thanks for looking into this problem.
 
The attached patch removes this restriction.
it need more polish, but it's good enough to use it to verify the bug I reported
on
https://postgr.es/m/CACJufxHZsgn3zM5g-x7YmtFGzNDnRwR07S+GYfiUs+tZ45MDDw@mail.gmail.com

I think we can keep the discussion in your thread. Actually, I got this idea from your discussion.

But for this topic, I don't want to go that far in the first place, because completely allowing that might require more discussion.

Here I am just proposing a patch for a small step. When any dependent generated column has SET EXPRESSION, then we can allow the column type change:

```
    -- Before this patch, the recommended usage was:
    ALTER TABLE gtest
      DROP COLUMN x,
      ALTER COLUMN a TYPE float8,
      ADD COLUMN x bigint GENERATED ALWAYS AS ((a::int + b) * 2) STORED;

    -- With this patch, the statement is simplified as:
    ALTER TABLE gtest
      ALTER COLUMN a TYPE float8,
      ALTER COLUMN x SET EXPRESSION ((a::int + b) * 2);
```

Best regards,
Chao Li (Evan)
---------------------
HighGo Software Co., Ltd.
Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Logical Replication of sequences
Next
From: Heikki Linnakangas
Date:
Subject: Re: Optimizing ResouceOwner to speed up COPY