Skip site navigation (1) Skip section navigation (2)

Re: renameatt() can rename attribute of index, sequence, ...

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: renameatt() can rename attribute of index, sequence, ...
Date: 2010-03-03 05:26:29
Message-ID: 603c8f071003022126k3e172e9h82a9f1ab93b3d613@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2010/3/2 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> Is it an expected behavior?
>
>  postgres=> CREATE SEQUENCE s;
>  CREATE SEQUENCE
>  postgres=> ALTER TABLE s RENAME sequence_name TO abcd;
>  ALTER TABLE
>
>  postgres=> CREATE TABLE t (a int primary key, b text);
>  NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "t_pkey" for table "t"
>  CREATE TABLE
>  postgres=> ALTER TABLE t_pkey RENAME a TO xyz;
>  ALTER TABLE
>
> The documentation says:
>  http://developer.postgresql.org/pgdocs/postgres/sql-altertable.html
>
>    :
>  RENAME
>    The RENAME forms change the name of a table (or an index, sequence, or view) or
>    the name of an individual column in a table. There is no effect on the stored data.
>
> It seems to me the renameatt() should check relkind of the specified relation, and
> raise an error if relkind != RELKIND_RELATION.

Are we talking about renameatt() or RenameRelation()?  Letting
RenameRelation() rename whatever seems fairly harmless; renameatt(),
on the other hand, should probably refuse to allow this:

CREATE SEQUENCE foo;
ALTER TABLE foo RENAME COLUMN is_cycled TO bob;

...because that's just weird.  Tables, indexes, and views make sense,
but the attributes of a sequence should be nailed down I think;
they're basically system properties.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: A. KretschmerDate: 2010-03-03 05:55:43
Subject: Re: [GENERAL] to_timestamp() and quarters
Previous:From: Robert HaasDate: 2010-03-03 05:13:46
Subject: Re: Avoiding bad prepared-statement plans.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group