Re: pg_dump versus SERIAL, round N

Tom Lane wrote:
> Basically this change would mean that you'd be allowed to DROP the
> sequence with CASCADE (hence removing all the DEFAULT expressions that
> use it) without being forced to drop the owning column as such. That
> seems to square better with the idea that the column "owns" the
> sequence. In this new approach I don't think we are considering the
> sequence as an integral part of the column's implementation, so
> INTERNAL seems too strong.

Basically as I see it, instead of making SERIAL a macro in the database,
you are making it a macro in pg_dump, and on reload, you are creating a
way to relink the sequence to the column so it still functions as a
black box when in the database. That seems like a fine solution. Our
two SERIAL TODO items are:

* %Disallow changing DEFAULT expression of a SERIAL column?

This should be done only if the existing SERIAL problems cannot be
fixed.

* %Disallow ALTER SEQUENCE changes for SERIAL sequences because pg_dump
does not dump the changes

How would your proposal handle these cases? Would changing the default
of a SERIAL column detach the column/sequence dependency? I would think
so, and dump/reload would work fine. And ALTER SEQUENCE would dump fine
too, because you are doing the split in pg_dump?

> BTW, will anyone object to doing this now, ie, for 8.2? I claim it's a
> bug fix not a new feature ;-)

I knew that part was coming, and obviously you knew I knew too. ;-)

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +