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  (Andrew Dunstan <andrew@dunslane.net>)
Re: ALTER TABLE ... TO ... to change related names  (Dennis Björklund <db@zigo.dhs.org>)
Список 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 по дате отправления:

Предыдущее
От: Scott Lamb
Дата:
Сообщение: Re: Date input changed in 7.4 ?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: database corruption