From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: serial drop error |
Date: | 2004-12-06 17:49:47 |
Message-ID: | 200412061049.47091.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Monday December 6 2004 9:45, Ed L. wrote:
> On Sun, 05 Dec 2004 14:54:38, Tom Lane wrote:
> > On Sunday December 5 2004 12:34, Ed L. wrote:
> > > The following queries result in a dropped sequence, but IMO should
> > > not:
> > >
> > > create table foo(id serial);
> > > create table bar(id integer not null nextval('foo_id_seq'::text));
> > > alter table foo alter column id drop default;
> > > drop table foo;
> > >
> > I don't think that follows at all. The sequence is associated with the
> > column because of use of the "serial" declaration; dropping the default
> > expression doesn't change that.
Looking into this a little farther, I see from the 7.3.4 docs it's not a
bug, it's a new feature. Still, I'll whine that I don't see the point of
restricting the re-use/adoption of existing serial-created sequences, and
the restriction is biting me. Yes, I see there are ways to work around
this in the future. Doesn't help much managing existing clusters whose
schemas weren't adjusted in the move to 7.3 to account for this design
change. I can see the point of *not* dropping the sequence unless the
owning column is dropped. I just don't see the point of disabling the
useful ability to decouple the sequence-column association, and dropping
the default seems the most reasonable way to do that.
Ed
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-12-06 18:22:35 | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |
Previous Message | Ed L. | 2004-12-06 16:45:39 | Re: serial drop error |