25.03.2017 0:16, Lester Caine wrote: > On 24/03/17 21:42, Vlad Khorsun wrote: >> 24.03.2017 21:36, Lester Caine wrote: >>> On 24/03/17 17:57, Vlad Khorsun wrote: >>>>> What must be done is specified exactly. And we should suppose that in >>>>> all other aspects data stored in database should not be changed - >>>> What data is *stored* ? >>> For any field, the data that is loaded initially or later modified. And >>> I REPEAT ... if the field was originally NULL it should remain NULL >>> until a specific record update modifies it. It should not be returning >>> some DEFAULT value that was added later UNLESS the constraints are >>> changed to require the NULL value to be populated, but that should not >>> be populated 'magically' and the SQL spec does not override that basic >>> function of a value in an existing record? The DEFAULT value should only >>> be used to replace a NULL value when a record is added ... full stop. > >> Engine substitute default value if and only if NOT NULL field was added >> and DEFAULT value was specified. Engine not allow to add NOT NULL field >> without DEFAULT. If NULLable field was added engine will return NULL's >> for that field at existing old records despite of precence of DEFAULT value. >> >> Is it OK ? > > That is what I would expect to see ... > As I stated in SET's reply I would expect to manage the change of a > default as appropriate, but the fall back should always be the stored > values? You would only see a 'new' default value if you added it, not if > you simply changed the metadata?
If i understand you correctly - fb3 works the way you expect. You may look at my sample at CORE-5507 to see how it works. 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
