Re: Does RENAME TABLE rename associated identity sequence?

Isaac Morland <isaac.morland@gmail.com> writes:
> On Thu, 24 Apr 2025 at 05:53, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
> wrote:
>> If there's any problem, IMO, ALTER TABLE ... RENAME ... should rename the
>> sequence too since the identity sequences are created implicitly when the
>> table is created, so they should be renamed implicitly. We should not
>> require WITH SEQUENCE clause.

> My concern would be what happens if the new sequence name is not available.
> I suppose the simplest behaviour might be to skip renaming the sequence in
> that case, perhaps raising a warning.

We do not rename any other subsidiary objects such as indexes.
Why would we rename a sequence (which has a lot more reason
to be considered an independent object than an index does)?

regression=# create table foo (i int primary key);
CREATE TABLE
regression=# \d+ foo
                                           Table "public.foo"
 Column |  Type   | Collation | Nullable | Default | Storage | Compression | Stats target | Description 
--------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
 i      | integer |           | not null |         | plain   |             |              | 
Indexes:
    "foo_pkey" PRIMARY KEY, btree (i)
Not-null constraints:
    "foo_i_not_null" NOT NULL "i"
Access method: heap

regression=# alter table foo rename to bar;
ALTER TABLE
regression=# \d+ bar
                                           Table "public.bar"
 Column |  Type   | Collation | Nullable | Default | Storage | Compression | Stats target | Description 
--------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
 i      | integer |           | not null |         | plain   |             |              | 
Indexes:
    "foo_pkey" PRIMARY KEY, btree (i)
Not-null constraints:
    "foo_i_not_null" NOT NULL "i"
Access method: heap

I think it's up to the user to rename subsidiary objects if
they wish to do so.

			regards, tom lane