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
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 |