On Sat, 30 Aug 2003, Tom Lane wrote:... 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.
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');
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.
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
