Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression - Mailing list pgsql-hackers

From Amul Sul
Subject Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
Date
Msg-id CAAJ_b96=1ZRD86-3tCzdPtzJKCxsnOfN7res91Mv9utZ1XpziQ@mail.gmail.com
Whole thread Raw
In response to Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression  (Maxim Orlov <orlovmg@gmail.com>)
Responses Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
List pgsql-hackers
On Wed, Sep 13, 2023 at 2:28 PM Maxim Orlov <orlovmg@gmail.com> wrote:
Hi!

I'm pretty much like the idea of the patch. Looks like an overlook in SQL standard for me.
Anyway, patch apply with no conflicts and implements described functionality.


Thank you for looking at this.
 
On Fri, 25 Aug 2023 at 03:06, Vik Fearing <vik@postgresfriends.org> wrote:

I don't like this part of the patch at all.  Not only is the
documentation only half baked, but the entire concept of the two
commands is different.  Especially since I believe the command should
also create a generated column from a non-generated one.

But I have to agree with Vik Fearing, we can make this patch better, should we?
I totally understand your intentions to keep the code flow simple and reuse existing code as much 
as possible. But in terms of semantics of these commands, they are quite different from each other.
And in terms of reading of the code, this makes it even harder to understand what is going on here.
So, in my view, consider split these commands.

Ok, probably, I would work in that direction. I did the same thing that
SET/DROP DEFAULT does, despite semantic differences, and also, if I am not
missing anything, the code complexity should be the same as that.

Regards,
Amul

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Reducing connection overhead in pg_upgrade compat check phase
Next
From: Amit Kapila
Date:
Subject: Re: subscription TAP test has unused $result