On 2016-10-05 18:58:47 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2016-10-05 15:44:56 -0700, Jeff Janes wrote: > >>> No, "a second “exist default"" was mentioned, i.e. it is an additional > >>> column in a system table (pg_attribute) as default column values of > >>> the "pre-alter" era. It solves changing of the default expression of > >>> the same column later. > > > Don't think that actually solves the issue. The default might be unset > > for a while, for example. Essentially you'd need to be able to associate > > arbitrary number of default values with an arbitrary set of rows. > > I think it does work, as long as the "exists default" is immutable. > (For safety, personally, I'd restrict it to be a verbatim constant.) > The point is that you apply that when you are reading a row that has > so few columns that it must predate the original ALTER TABLE ADD COLUMN. > Subsequent ADD/DROP/SET DEFAULT affect the "active default" and hence > insertions that happen after them, but they don't affect the > interpretation of old rows. And of course all rows inserted after the > ADD COLUMN contain explicit values of the column, so their meaning is > unaffected in any case.
Err, yes. I forgot that altering the default of an existing column doesn't set the default for existing values. Sorry for the noise. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
