Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
От | Amul Sul |
---|---|
Тема | Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression |
Дата | |
Msg-id | CAAJ_b96=1ZRD86-3tCzdPtzJKCxsnOfN7res91Mv9utZ1XpziQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression (Maxim Orlov <orlovmg@gmail.com>) |
Ответы |
Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
|
Список | pgsql-hackers |
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 muchas 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.
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
В списке pgsql-hackers по дате отправления: