Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression

From: Amul Sul <sulamul(at)gmail(dot)com>
To: Maxim Orlov <orlovmg(at)gmail(dot)com>
Cc: Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
Date: 2023-09-14 09:04:31
Message-ID: CAAJ_b96=1ZRD86-3tCzdPtzJKCxsnOfN7res91Mv9utZ1XpziQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 13, 2023 at 2:28 PM Maxim Orlov <orlovmg(at)gmail(dot)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(at)postgresfriends(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-09-14 09:10:35 Re: subscription TAP test has unused $result
Previous Message Daniel Gustafsson 2023-09-14 08:48:45 Re: Reducing connection overhead in pg_upgrade compat check phase