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@gmail.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