Обсуждение: CREATE TABLE glitch -fix request for 7.2
Tom, Peter, Stephan, et al.: Here's a glitch that's bothered me for a while (ver 7.0 -> 7.2b4 ) inPostgreSQL DDL statements. I was thinking that since7.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 aSERIAL primary key (I do this all the timeto build my databases) 2. Run the script once to create the table. You'll get a error (no table todrop) but that doesn't matter. 3. Run the script a second time, as if you were making changes to the datastructure and needed to rebuild. 4. You will get an error telling you that "table1_id_seq" already exists, andthe CREATE TABLE statement will fail. This is very user-unfriendly behaviour, especially in a database that stilldoes not support about 50% of ALTER TABLE. Ispend a fair amount of extratime deleting SERIAL sequences when I am doing the database-building part ofthe developmentprocess. Can we change this behavior, please? I'd suppose that it would require you tocreate some sort of permanent link betweenSERIAL columns and the sequencesthey spawn. -Josh Berkus ______AGLIO DATABASE SOLUTIONS___________________________ Josh Berkus Complete informationtechnology josh@agliodbs.com and data management solutions (415) 565-7293 for law firms, small businesses fax 621-2533 and non-profit organizations. San Francisco
"Josh Berkus" <josh@agliodbs.com> writes:
> I was thinking that since 7.2 is still in beta,
> that you could fix it this version.
Not a chance. Sorry. If you'd cared to submit some code six months
ago... but this is a nontrivial change, the problem has been of long
standing and yet hasn't especially motivated anyone to work on it, and
we are *not* holding up 7.2 any more for anything but critical bugs.
regards, tom lane
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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom, > Not a chance. Sorry. If you'd cared to submit some code six months > ago... but this is a nontrivial change, the problem has been of long > standing and yet hasn't especially motivated anyone to work on it, and > we are *not* holding up 7.2 any more for anything but critical bugs. OK. In 7.3, then? Maybe? -Josh ______AGLIO DATABASE SOLUTIONS___________________________ Josh Berkus Complete informationtechnology josh@agliodbs.com and data management solutions (415) 565-7293 for law firms, small businesses fax 621-2533 and non-profit organizations. San Francisco
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