Dennis Björklund wrote:
>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');
>
... or using schema paths. Possibly you could add the ability to select
foo.x.nextval/foo.x.nextval( ). The path to that sequence would change
if the table name were changed, but you'd have to make sure that any
other table(s) referencing that sequence would be altered as well to
reflect the new location.
Using a method simlar to this would also prevent the sequence name
collision problem with long named tables and long named columns.
Could the dependency tracker handle this?
>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.
>
>
>