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 [EMAIL PROTECTED]
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
