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
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 |