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
cannotbe  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@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +