Re: ALTER TABLE ... TO ... to change related names
От | Tom Lane |
---|---|
Тема | Re: ALTER TABLE ... TO ... to change related names |
Дата | |
Msg-id | 1692.1062279929@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER TABLE ... TO ... to change related names (Dennis Björklund <db@zigo.dhs.org>) |
Ответы |
Re: ALTER TABLE ... TO ... to change related names
Re: ALTER TABLE ... TO ... to change related names |
Список | pgsql-hackers |
Dennis Björklund <db@zigo.dhs.org> writes: > I don't understand why the serial columns sequence should be visible as > other sequences. Backwards compatibility, if nothing else. Are you prepared to break every existing dump file that hasCREATE TABLE ser (f1 serial);SELECT pg_catalog.setval('ser_f1_seq', 1, false); > create table foo (x serial); > select nextval('foo.x'); This conflicts with the existing provisions for accessing sequences using ordinary schema-qualified names ('schema.sequence'). The work I would actually like to see getting done in this area is the existing TODO item about using Oracle-compatible syntax for nextval et al, namely that you can writesequence.nextval orschema.sequence.nextval rather than nextval('sequence') or nextval('schema.sequence'). The internal representation of such a thing could use the sequence OID to refer to the sequence, and would thereby be inherently rename-proof (not to mention visible to the dependency tracker, so's you couldn't accidentally drop a sequence that's still mentioned in some default expression). There is speculation in the archives about how we might implement this and even arrange to auto-migrate existing schemas during dump/reload. regards, tom lane
В списке pgsql-hackers по дате отправления: