Re: ALTER INDEX .. RENAME allows to rename tables/views as well - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: ALTER INDEX .. RENAME allows to rename tables/views as well
Date
Msg-id 202110062344.umcztyngqtvu@alvherre.pgsql
Whole thread Raw
In response to Re: ALTER INDEX .. RENAME allows to rename tables/views as well  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: ALTER INDEX .. RENAME allows to rename tables/views as well  ("Bossart, Nathan" <bossartn@amazon.com>)
List 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.



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
Next
From: Jaime Casanova
Date:
Subject: Re: [Patch] ALTER SYSTEM READ ONLY