Re: BUG #15087: ALTER INDEX RENAME renames table if matches

On 02/26/2018 12:18 AM, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 15087
> Logged by: Ezequiel Tolnay
> Email address: etolnay(at)gmail(dot)com
> PostgreSQL version: 10.0
> Operating system: Windows 10
> Description:
>
> A table name mytable can be renamed to newtable via:
>
> ALTER INDEX mytable RENAME TO newtable
>
> This is probably incorrect. It should either raise an error (as it does with
> ALTER TABLE if the name supplied is that of an index), or better, when
> specified IF EXISTS, simply do nothing.
>

Hmmm, I agree that seems suspicious and surprising. But looking at the
code, I see that RangeVarCallbackForAlterRelation does this:

/*
* For compatibility with prior releases, we allow ALTER TABLE to
* be used with most other types of relations (but not composite
* types). We allow similar flexibility for ALTER INDEX in the case
* of RENAME, but not otherwise. Otherwise, the user must select
* the correct form of the command for the relation at issue.
*/

...

/*
* Don't allow ALTER TABLE on composite types. We want people to
* use ALTER TYPE for that.
*/
if (reltype != OBJECT_TYPE && relkind == RELKIND_COMPOSITE_TYPE)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("\"%s\" is a composite type", rv->relname),
errhint("Use ALTER TYPE instead.")));

So the behavior seems intentional, because of backwards compatibility.

I personally wouldn't mind changing it - it certainly seems surprising,
and singling out RENAME seems strange. But maybe it'd break more things
than I imagine.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services