On Thu, May 21, 2009 at 11:13 AM, Greg Stark <stark@enterprisedb.com> wrote:
> On Thu, May 21, 2009 at 3:45 PM, Tom Lane <tgl@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
How would this scheme prevent you from doing that? The tuples that
are added subsequent to the initial ADD COLUMN will have the value for
that column in it, whether NULL or otherwise, default or not. The
only thing you need to store is the value to be used (in place of
NULL) when reading an old, short tuple.
> 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.
I was also wondering whether there might be some gotchas in this area.
...Robert