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: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Maxim Orlov <orlovmg@gmail.com>, Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2023-09-18T08:29:13Z
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 Thu, Sep 14, 2023 at 7:23 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
wrote:

> Hi Amul,
> I share others opinion that this feature is useful.
>
> >> 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.
>
> If we allow SET EXPRESSION to convert a non-generated column to a
> generated one, the current way of handling ONLY would yield mismatch
> between parent and child. That's not allowed as per the documentation
> [1]. In that sense not allowing SET to change the GENERATED status is
> better. I think that can be added as a V2 feature, if it overly
> complicates the patch Or at least till a point that becomes part of
> SQL standard.
>

Yes, that going to be a bit complicated including the case trying to convert
the non-generated column of a child table where need to find all the
ancestors
and siblings and make the same changes.

Regards,
Amul