On Thu, May 21, 2009 at 4:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@enterprisedb.com> writes: >> 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. > > Yeah ... I don't see exactly what it would buy to restrict it to just > the first such value.
Well it wouldn't buy you steady-state space savings or performance improvements. What it would buy you is a much narrowed set of circumstances where ALTER TABLE ADD COLUMN goes from a fast O(1) catalog change to a complete table rewrite. The use cases covered such as "boolean DEFAULT false" or "integer DEFAULT 0" are extremely common. I think users today often avoid the full table rewrite either make their application treat null as implicitly the default value or do a piecemeal rewrite using updates. I think Robert Haas is right that we could handle any stable expression by evaluating the expression once and storing only the final resulting value as a constant. That would avoid the problems with dependencies and later changes to functions. Another gotcha is that the default value might be very large.... It can't be very common but I suppose we would have to take some care around that. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
