In some recent activity on the patches list about responding to bug #2073, http://archives.postgresql.org/pgsql-bugs/2005-11/msg00303.php we've been discussing various possible tweaks to the behavior of dropping or modifying a serial column. The hacks involved with SERIAL seem to me to be getting uglier and uglier, and I think it's time to take a step back and consider what we really want SERIAL to act like.
It seems to me there are two basic philosophies at war here: 1. A serial column is a "black box" that you're not supposed to muck with the innards of. This philosophy leads to the proposal that we disallow modifying the column default expression of a serial column, and will ultimately lead to thoughts like trying to hide the associated sequence from direct access at all. 2. A serial declaration is just a "macro" for setting up a sequence and a column default expression. This was the original viewpoint and indeed is still what it says in the documentation: http://developer.postgresql.org/docs/postgres/datatype-numeric.html#DATATYPE-SERIAL This is nice and simple and easy to understand, but it leads to usually-undesirable behaviors like having the sequence still be there if the column is dropped. We started with #2 and have been moving slowly towards #1, but I think there's a limit to how far we want to go in that direction. A black box approach isn't especially user-friendly in my opinion; it's not solving any problems, it's just refusing to deal with the implications of ALTER TABLE and friends. What's more, the further we go in that direction the more problems we'll have in pg_dump. We've already got issues there; for example, if someone renames a serial's sequence or tweaks its sequence parameters, this will not be preserved by dump/restore. I'm wondering if we shouldn't reverse this trend and try to go back to a fairly pure version of philosophy #2. It'd certainly make pg_dump's life a lot easier if it could dump a serial sequence as just an ordinary sequence, instead of having to make sure it's created via SERIAL. One original argument for putting in a hidden dependency centered around the fact that if you dropped the sequence, you'd break the column default. But we have a much better answer to that as of PG 8.1: the nextval() invocation is itself dependent on the sequence by means of the regclass-literal mechanism. We don't need the extra dependency to prevent that. The other concern the hidden dependency addresses is the idea that the sequence ought to be silently dropped if the table (or just the column) is dropped. I wonder though if that behavior is really worth the increasing contortions we're going through to try to make things work conveniently/transparently in other respects. We're buying simplicity for one case at the cost of tremendous complication for other cases. In short, I think there's a reasonably good case to be made for losing the hidden dependency and re-adopting the viewpoint that saying SERIAL is *exactly* the same as making a sequence and then making a default expression that uses the sequence. Nothing behind the curtain. Comments, other opinions? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
