On 2017-03-24 21:14, Mark Rotteveel wrote: > To me 2ii) means that the behaviour should be that the newly added > column **has** the value of the default clause, this can also be > inferred from 11.5 <default clause>. > > And I think clause 4 is relevant: > > """ > 4) In all other respects, the specification of a <column definition> in > an <alter table statement> has the same > effect as specification of the <column definition> in the <table > definition> for T would have had. > """ > > If the column had been added with create table, but rows had been > inserted without values for that column, then those rows would have had > the default as the actual value, and those would not be changed by > subsequent alteration of the default. > > And 11.13 <set column default clause> does not state that the value of > existing columns should be changed. > > In other words: the current behaviour in Firebird 3 is the correct > behaviour as expected by the SQL standard. I do not think we should > revert that for reasons of preserving legacy bugs. > > I will take a more in depth look this weekend.
Another reason I just came up with: Consider scenario: 1. create table 2. add rows 3. add column with default 4. backup + restore database 5. alter default of column added in step 3 After step 5 the values should be identical if the step 4 had been executed or not. Mark ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
