Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: movead li <movead.li@highgo.ca>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2019-07-02T02:00:29Z
Lists: pgsql-hackers
movead li <movead.li@highgo.ca> writes: > I applied the 'alter-table-with-recursive-process-utility-calls-wip.patch' > on the master(e788e849addd56007a0e75f3b5514f294a0f3bca). And > when I test the cases, I find it works well on 'alter table t1 add column > f2 int not null, alter column f2 add generated always as identity' case, > but it doesn't work on #14827, #15180, #15670, #15710. 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 to allow ALTER TABLE to call other utility statements --- or, if we aren't going to do that as Robert seems not to want to, what exactly we're going to do instead. The patch at hand does fix some ALTER TABLE ... IDENTITY bugs, because fixing those doesn't require any conditional execution of utility statements. But we'll need infrastructure for such conditional execution to fix the original bugs. I don't see much point in working on that part until we have some agreement about how to handle what this patch is already doing. regards, tom lane
Commits
-
Clarify behavior of adding and altering a column in same ALTER command.
- 9b9c5f279e82 13.0 landed
-
Restructure ALTER TABLE execution to fix assorted bugs.
- 1281a5c907b4 13.0 landed
-
doc: Add best practises section to partitioning docs
- e788e849addd 12.0 cited
-
Allow on-the-fly capture of DDL event details
- b488c580aef4 9.5.0 cited