I stand corrected. Thanks for the info. :)
Tom Lane wrote:
> John Burski <johnb@911ep.com> writes:
> > When you drop a table, you should, IMO, drop the related sequences and indices
> > as well (they don't automatically drop).
>
> Correction: indexes *are* dropped automatically when you drop their
> table.
>
> The sequence made to support a SERIAL column should be dropped
> automatically when the table is dropped, but is not at present.
> This will probably be fixed in some future release.
> (I've heard some people suggest that they like the existing behavior,
> but I think if you want a persistent sequence you should make it
> with an explicit CREATE SEQUENCE command.)
>
> This being the novice list, it should perhaps be pointed out that
> SERIAL isn't a real datatype; it's just syntactic sugar for an
> integer column with a default value expression, like so:
>
> create table foo (bar serial);
>
> is equivalent to
>
> create sequence foo_bar_seq;
>
> create table foo (bar integer unique not null
> default nextval('foo_bar_seq'));
>
> If you write it out longhand like this, you can obtain effects
> like having several different tables draw serial numbers from
> the same sequence, which comes in handy sometimes. If you've
> set up an arrangement like that, then indeed you don't want the
> sequence to be dropped just because you dropped one of the tables.
> But ISTM that you should create the sequence manually when you
> are going to do this. SERIAL is supposed to be a canned way of
> setting up the simplest case, and in the simplest case I think
> auto-drop is what you'd want...
>
> regards, tom lane
--
John Burski
I.T. Manager and Systems Administration
911 Emergency Products, Inc.
25 Sixth Avenue North
Saint Cloud, MN 56303
John.Burski@911ep.com
800-863-6911, extension 221
FAX: 800-863-2991
www.911ep.com