Re: [GENERAL] Sequences/defaults and pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Sequences/defaults and pg_dump
Date
Msg-id 4263.1139515922@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Sequences/defaults and pg_dump  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [GENERAL] Sequences/defaults and pg_dump
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Upcoming re-releases
Next
From: Greg Stark
Date:
Subject: Re: PostgreSQL 8.0.6 crash