On Thu, May 21, 2009 at 10:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Sam Mason <s...@samason.me.uk> writes: >> On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote: >>> ALTER TABLE ... ADD COLUMN ... NULL; >>> >>> (nullable without a default value). This is because of NULL bitmap in >>> tuples. And it's greatest feature for a developer! > >> I don't think this is because of the "NULL bitmap". > > No, it isn't. It's because each tuple includes the actual count of > fields it contains (t_natts or HeapTupleHeaderGetNatts), and the value > extraction routines are coded to assume that references to fields > beyond that number should yield NULL. So the ALTER can just leave > the existing rows alone --- only when you update a row will it change > to include the newly added field(s). > > AFAICS there's no good way to scale that solution up to handling > non-null values. > >> 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?
I think what Sam is proposing is that, in addition to storing the default value for a column, you could store the value at the time the column was added. These might be the same if the default is a constant and has never been modified, or they might be different. This would even work for now() because it's stable, but it couldn't be used for a volatile function like random() or timeofday(), of course. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers