Tom Lane wrote: > If you insist on initially creating the sequence by saying SERIAL for > the first of the tables, and then saying DEFAULT nextval('foo_seq') > for the rest, then under both 8.1 and my proposal you'd not be able to > drop the first table without dropping the sequence (thus requiring you > to say CASCADE so that the other tables' defaults can be dropped). > The difference is that I'm proposing a way to decouple the sequence from > its original owning column and make it into a true freestanding object, > after which you could drop the first table without losing the sequence and > the other defaults. > For decoupling, you'd require ALTER SEQUENCE ... OWNER BY NONE to be executed, right? I basically doubt the concept of a single owner. I'd expect a sequence to be dropped from cascaded table dropping, if that was the last usage and dependencies existed. This would probably mean "multiple owners".
> Basically the proposed command allows you to convert from the case where > a sequence was created by SERIAL to the case where it was created > free-standing, or vice versa. > > The other change is that using an AUTO instead of INTERNAL dependency > makes it legal to drop the sequence without dropping the column. > Sounds fine. > > AFAICS this doesn't disallow anything you could do before, and it > allows fixing the problems pg_dump is having. Is there something > you need it to do that it doesn't do? > Sequence cleanup with multiple tables (multiple owners). Regards, Andreas ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match