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
