24.03.2017 8:14, Dmitry Yemanov wrote: > 24.03.2017 02:29, Mark Rotteveel wrote: > >> To me the behavior described under "actual" intuitively sounds like the >> correct behavior. Why do you expect that the column value would change >> to 'ABC'? > > This is really a tricky case. The "replace non-existing value with the > default one" hack is a native Firebird feature that's not covered by the > standard, it allows adding fields without updating the whole table. The > question is what default value must be used, if there are/were many. > > Firebird is known to upgrade the record format while reading. "Upgrade" > here means using the latest (aka current) format. The current format is > the one that can be seen in RDB$RELATION_FIELDS. So one may expect that > the default value to be used is also the latest one, that's stored in > RDB$ tables. IIRC, this is how FB 2.5 works.
Exactly. When i read the table and know that some field should have default value, i expect to see this value at system catalog. Another example - i add not null column with wrong default value and going to correct this wrong default value. Should i update whole table to do it ? > From another side, storing the default value inside the format is a > smart hack that allows to avoid updating the table. It was designed to > act like an implicit update but without the overhead. And considering > the update semantics, the new behaviour may look correct. Also true > The big question is what expectations are better suitable to our users. The one that already works for years and well known ? ;) Regards, Vlad ------------------------------------------------------------------------------ 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
