Re: Rearranging ALTER TABLE to avoid multi-operations bugs

> This review seems not very on-point, because I made no claim to have fixed
> any of those bugs. The issue at the moment is how to structure the code

I am sorry for that and I have another question now. I researched the related
code and find something as below:
Code:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
case AT_AddIdentity:
{
...
attnum = get_attnum(relid, cmd->name);
/*
* if attribute not found, something will error about it
* later
*/
if (attnum != InvalidAttrNumber)
generateSerialExtraStmts(&cxt, newdef,
get_atttype(relid, attnum),def->options, true,
NULL, NULL);
​...
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Test case1:
################################################
create table t10 (f1 int);
alter table t10 add column f2 int not null,
alter column f2 add generated always as identity;
################################################
I find that the value of 'attnum' is 0 because now we do not have the 'f2'
column when I run the Test case1, so it can not generate a sequence
(because it can not run the generateSerialExtraStmts function).
You can see the code annotation that 'something will error about it later',
so I thank it may be an error report instead of executing successfully.

Test case2:
################################################
create table t11 (f1 int);
alter table t11 add column f2 int,
alter column f2 type int8;
################################################
Code about 'alter column type' have the same code annotation, and
if you run the Test case2, then you can get an error report. I use Test case2
to prove that it may be an error report instead of executing successfully.

--
Movead.Li

The new status of this patch is: Waiting on Author