Subject | Re: [firebird-support] Firebird 2.5 - Alter table - drop default - bug or feature |
---|---|
Author | Lester Caine |
Post date | 2017-04-27T09:53:28Z |
On 26/04/17 16:34, Ann Harrison aharrison@...
[firebird-support] wrote:
predate the arrival of Firebird ... if the change to metadata results in
a conflict, then *I* expect to resolve the conflict. Just as if I have
added just a NOT NULL and now need to populate the null fields.
indicates if that field is allowed to be flagged as null. The magic I'm
flagging here is if the field metadata provides a default value, and the
field does not actually store that value, but rather a new flag which
says 'default'. DEFAULT NOT NULL magically displays the current default
value for a null flagged field, while DEFAULT needs the extra flag to
distinguish between a null value and a default one. Returning to the 30
year old standard, once YOU have updated the table with a new value that
will be locked down in the stored records and the idea that a change to
the DEFAULT value will also change OLD default records is simply not
consistent with the way Firebird works?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
[firebird-support] wrote:
> If Firebird were to convert a record from its stored format through each intervening format, the result would be more logical but it would be a change to a behavior that's over 30 years old. And there are advantages to the current behavior. If you alter a table in a way that invalidates existing values, another alter table can undo the damage.That I think is my main 'objection' here ... having databases that
predate the arrival of Firebird ... if the change to metadata results in
a conflict, then *I* expect to resolve the conflict. Just as if I have
added just a NOT NULL and now need to populate the null fields.
>> The argument that other engines put forward is this idea that a recordThe field in the record indicates if it is null or not, and the metadata
>> does not need to store a full set of fields, some can be 'virtual' and
>> only exist when something is stored in them. I HOPE that this is not
>> something that Firebird plans to adopt? In my book the 'original value'
>> is always 'NULL' unless other rules require something replaces it, and
>> an empty field magically showing some default value is not a safe way of
>> working.
> Firebird doesn't store null fields, instead it stores an array of bits that indicate whether or not a field is null. Between that, compression, and computed fields, there's a lot of magic going on.
indicates if that field is allowed to be flagged as null. The magic I'm
flagging here is if the field metadata provides a default value, and the
field does not actually store that value, but rather a new flag which
says 'default'. DEFAULT NOT NULL magically displays the current default
value for a null flagged field, while DEFAULT needs the extra flag to
distinguish between a null value and a default one. Returning to the 30
year old standard, once YOU have updated the table with a new value that
will be locked down in the stored records and the idea that a change to
the DEFAULT value will also change OLD default records is simply not
consistent with the way Firebird works?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk