Horton

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

amul sul <sulamul@gmail.com>

View thread
From: Amul Sul <sulamul@gmail.com>
To: Maxim Orlov <orlovmg@gmail.com>
Cc: Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2023-09-14T09:04:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. ALTER TABLE command to change generation expression

  2. Refactor: separate function to find all objects depending on a column

  3. Turn AT_PASS_* macros into an enum

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