Re: ALTER TABLE ... TO ... to change related names - Mailing list pgsql-hackers

From Dennis Björklund
Subject Re: ALTER TABLE ... TO ... to change related names
Date
Msg-id Pine.LNX.4.44.0308301844110.4053-100000@zigo.dhs.org
Whole thread Raw
In response to Re: ALTER TABLE ... TO ... to change related names  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER TABLE ... TO ... to change related names
Re: ALTER TABLE ... TO ... to change related names
List pgsql-hackers
On Sat, 30 Aug 2003, Tom Lane wrote:

> It'd probably be reasonable to rename only those sequences that are
> connected to the target table/column by internal dependencies --- this
> indicates that they were created by a SERIAL column definition and not
> by manual operations.

I don't understand why the serial columns sequence should be visible as
other sequences. As a user (and not thinking of how it would be
implemented) I think it's much more logical if the serial column sequence
is hidden in the namespace of the table in some way (there is no such
namespace now I guess). Anyway, so that you can use it like this:

create table foo (x serial);
select nextval('foo.x');
select * from foo.x;

This also solves the problem to know what the sequence name is which you
have to know what to use in currval() and such.

Renaming a sequence in this setting is the same as renaming the column. Of 
someone tries to use nextval('foo.x') somewhere else and then rename the 
column they would expect that the nextval above would not work any more.

Also, just to make it clear, I think the notation foo.x should only work
when it is a serial column. If someone has created the sequence explictly
(visible outside the table) and have given it a name, then that is the
name to use. The database should not try to figure out that sequence from
the default or anything like that.

-- 
/Dennis



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE ... TO ... to change related names
Next
From: Bruce Momjian
Date:
Subject: Re: massive quotes?