Re: ALTER INDEX .. RENAME allows to rename tables/views as well
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, Onder Kalaci <onderk@microsoft.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-06T23:44:16Z
Lists: pgsql-hackers
On 2021-Oct-06, Bossart, Nathan wrote: > On 10/6/21, 3:44 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > > The situation for "ALTER some-other-relation-kind" is a bit more > > confused, because some cases throw errors and some don't; but I really > > doubt that tightening things up here will earn you anything but > > brickbats. I *definitely* don't agree with discarding the policy > > about ALTER TABLE, especially if it's only done for RENAME. > > I think we should at least consider adding this check for ALTER INDEX > since we choose a different lock level in that case. I agree -- letting ALTER INDEX process relations that aren't indexes is dangerous, with its current coding that uses a reduced lock level. But maybe erroring out is not necessary; can we instead loop, locking the object with ShareUpdateExclusive first, assuming it *is* an index, and if it isn't then we release and restart using the stronger lock this time? -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ Syntax error: function hell() needs an argument. Please choose what hell you want to involve.
Commits
-
Ensure correct lock level is used in ALTER ... RENAME
- c2c618ff1137 15.0 landed
- 842fe6123c8a 13.5 landed
- 6c8d1c197bd6 12.9 landed
- 3ce3fb2f7dc6 14.1 landed