Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
Date
Msg-id 5c844f1e-67d5-4b2f-8957-53044064c2ab@eisentraut.org
Whole thread Raw
In response to Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression  (Amul Sul <sulamul@gmail.com>)
Responses Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
List pgsql-hackers
On 13.11.23 14:07, Amul Sul wrote:
>     Also, it seems to me that the SET EXPRESSION variant should just do an
>     update of the catalog table instead of a drop and re-insert.
> 
> I am not sure if that is sufficient; we need to get rid of the 
> dependencies of
> existing expressions on other columns and/or objects that need to be 
> removed.
> The drop and re-insert does that easily.

Ok, good point.

>     The documentation needs some improvements:
> 
>     +    ALTER [ COLUMN ] <replaceable
>     class="parameter">column_name</replaceable> SET EXPRESSION <replaceable
>     class="parameter">expression</replaceable> STORED
> 
>     If we're going to follow the Db2 syntax, there should be an "AS" after
>     EXPRESSION.  And the implemented syntax requires parentheses, so they
>     should appear in the documentation.
> 
>     Also, the keyword STORED shouldn't be there.  (The same command should
>     be applicable to virtual generated columns in the future.)
> 
> I have omitted "AS" intentionally, to keep syntax similar to our existing
> ALTERCOLUMN... SET DEFAULT <a_expr>.  Let me know if you want
> me to add that.

Well, my idea was to follow the Db2 syntax.  Otherwise, we are adding 
yet another slightly different syntax to the world.  Even if we think 
our idea is slightly better, it doesn't seem worth it.

> The STORED suggested by Vik[1].  I think we could skip that if there is 
> no need
> to differentiate between stored and virtual columns at ALTER.

I think that suggestion was based on the idea that this would convert 
non-generated columns to generated columns, but we have dropped that idea.




pgsql-hackers by date:

Previous
From: "Kumar, Sachin"
Date:
Subject: Re: pg_upgrade failing for 200+ million Large Objects
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: possibility to read dumped table's name from file