Re: [GENERAL] Sequences/defaults and pg_dump

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] Sequences/defaults and pg_dump
Дата
Msg-id 4263.1139515922@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] Sequences/defaults and pg_dump  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [GENERAL] Sequences/defaults and pg_dump  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> If we are going to do something like that, I think we should take a hard
>> look at the idea I floated of putting SERIAL back to a pure
>> creation-time macro for type and default expression.  This is getting to
>> have way too much hidden behavior, and what we are buying for it is very
>> little as of 8.1.

> OK, but I was confused how 8.1 has improved the way SERIAL works.

I already said this up-thread, but: a plain old "DEFAULT nextval('foo')"
now has the properties that you can't drop sequence foo without dropping
the default expression, and renaming the sequence isn't a problem.  That
takes care of the worst problems that we invented the SERIAL dependency
for.  If we dropped the special sequence-to-column dependency that
SERIAL now adds, and got rid of the special pg_dump behavior for
serials, we'd have less code instead of more and it would work a lot
more transparently.  The only thing we'd lose is that dropping a column
originally declared as serial wouldn't implicitly drop the sequence.
That's somewhat annoying but I'm not convinced that preserving that one
thing is worth the amount of infrastructure that's getting built (and
I hope you don't think that Joachim's proposal will be the end of it).
Basically we're sticking more and more band-aids on a design that wasn't
such a great idea to start with.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Upcoming re-releases
Следующее
От: Greg Stark
Дата:
Сообщение: Re: PostgreSQL 8.0.6 crash