Re: newbie: renaming sequences task

From: craigp <craigp98072(at)yahoo(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: newbie: renaming sequences task
Date: 2008-03-04 23:35:46
Message-ID: 80057.75187.qm@web53904.mail.re2.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

--- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> The first one is really not related to the others --- it just proposes
> that when renaming a table or individual column, we should look for
> sequences "owned by" that column or columns, and rename them so that
> they still look like "table_column_seq". This is about 50%
> straightforward searching of pg_depend, and about 50% dealing with
> collisions --- if there's already something of that name, you'd need
> to go through the same type of fallback name selection that's already
> done when a serial column is first made.
>
> (Thinking about it, I kinda wonder whether we even *want* such behavior
> anymore. In the presence of ALTER SEQUENCE ... OWNED BY, it's entirely
> possible that an owned sequence has a name that's got nothing to do with
> table_column_seq, and which the user wouldn't really want us to forcibly
> rename. Maybe this TODO has been overtaken by events?)

Well, if we just look at the first one, I wonder (as well) whether or not it is
useful (and as you said, perhaps surprising in some cases).

I did a quick test, and neither sequences nor primary keys are renamed [1].
Maybe this should be the default behaviour, unless we give provide some other
option to ALTER TABLE RENAME? Another possibility might be to only rename
sequences and/or primary keys which had been created implicitly during table
creation (assuming that information is tracked)?

[1]
create table t1 (id serial8 primary key not null)

alter table t1 rename to t2

pk still named t1_pkey
sequence still named t1_id_seq

____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin M. Roy 2008-03-05 02:01:23 Re: 8.3.0 Core with concurrent vacuum fulls
Previous Message Tom Lane 2008-03-04 20:04:35 Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables