On Thu, Sep 14, 2023 at 7:23 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote:
> Hi Amul, > I share others opinion that this feature is useful. > > >> On Fri, 25 Aug 2023 at 03:06, Vik Fearing <v...@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
