Re: CREATE TABLE glitch -fix request for 7.2

Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Josh Berkus wrote:
> > Tom, Peter, Stephan, et al.:
> > 
> > Here's a glitch that's bothered me for a while (ver 7.0 -> 7.2b4 ) in
> >  PostgreSQL DDL statements.  I was thinking that since 7.2 is still in beta,
> >  that you could fix it this version.
> > 
> > To produce the glitch:
> > 1. Create a SQL script file that drops a table, then creates that table with a
> >  SERIAL primary key (I do this all the time to build my databases)
> > 2. Run the script once to create the table.  You'll get a error (no table to
> >  drop) but that doesn't matter.
> > 3. Run the script a second time, as if you were making changes to the data
> >  structure and needed to rebuild.  
> > 4. You will get an error telling you that "table1_id_seq" already exists, and
> >  the CREATE TABLE statement will fail.
> > 
> > This is very user-unfriendly behaviour, especially in a database that still
> >  does not support about 50% of ALTER TABLE.  I spend a fair amount of extra
> >  time deleting SERIAL sequences when I am doing the database-building part of
> >  the development process.
> > 
> > Can we change this behavior, please?  I'd suppose that it would require you to
> >  create some sort of permanent link between SERIAL columns and the sequences
> >  they spawn.
> 
> We need pg_depend table to track dependency of sequence on specific
> tables, hopefully in >=7.3.

In the meantime Josh the simple workaround is to not use the SERIAL
type.  Instead when you create your SQL script create the sequences
manually (that way you can drop them manually as well.  My SQL scripts
look like this:

DROP TABLE prod_journal;
DROP SEQUENCE prod_journal_id_seq;

BEGIN;

CREATE SEQUENCE prod_journal_id_seq;

CREATE TABLE prod_journal (      id            int PRIMARY KEY             DEFAULT nextval('prod_journal_id_seq'),
...

You undoubtedly get the picture by now.  With the right text editor
creating a template for this sort of thing is almost as easy as using
the SERIAL keyword and a whole lot more flexible.

More importantly, if I want to run the script again and rebuild my
schema, everything works as expected.

Jason