On Thu, May 21, 2009 at 3:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> All that needs to be tracked is the "first" default value (this is >> currently assumed to be NULL). > > You're being a bit vague, but in any case I don't think it can work > for non-constant defaults (consider DEFAULT NOW()). And what about > ALTER COLUMN DEFAULT? > > (BTW, I'm quite sure schemes like this have been discussed before. > Check the archives...)
Schemes like this have been discussed before but I don't think we considered applying the limitation that only the "first" default value would be covered. We always wanted to be able to handle new defaults or making a non-null column nullable later. I think the main motivation in the past was space savings for default values rather than making adding new non-null columns cheap. AFAICS as long as we only want to handle newly created non-nullable columns with initial defaults that are applied when the column is added then we could actually handle it by storing the initial default value in the catalog and keeping it in the tupledesc at all times. If you later change the default then it would only affect newly inserted rows which will have the new default value explicitly included anyways. And if likewise if you later make the row nullable the column will be explicitly listed in natts and the null bitmap. One gotcha I can think of is if the default expression depends on something like a type. If the default is later changed then people might be surprised to find there's still an invisible dependency on the type. But if it's limited to simple constants that should minimize that issue quite a bit. At least for types the column itself will have the same dependency anyways. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
