Re: [Firebird-devel] Adding NOT NULL fields with DEFAULT

[Adriano d. S. F. <adr...@gm...>]

Helen Borrie wrote:
> At 07:46 AM 15/11/2009, Adriano dos Santos Fernandes wrote:
>> Vlad Khorsun wrote:
>>>     Sounds not bad but will not work if complex expressions referencing another fields from the same
>>> table is allowed by standard.
>>>
>> The standard mentions only simple expressions, like we have now:
>>
>> <default clause> ::=
>>  DEFAULT <default option>
>>
>> <default option> ::=
>>    <literal>
>>  | <datetime value function>
>>  | USER
>>  | CURRENT_USER
>>  | CURRENT_ROLE
>>  | SESSION_USER
>>  | SYSTEM_USER
>>  | CURRENT_CATALOG
>>  | CURRENT_SCHEMA
>>  | CURRENT_PATH
>>  | <implicitly typed value specification>
>>
>> <datetime value function> ::=
>>    <current date value function>
>>  | <current time value function>
>>  | <current timestamp value function>
>>  | <current local time value function>
>>  | <current local timestamp value function>
> 
> Let me see....you want to change (break) the standard behaviour for inserts and "enrich" it so that "default" becomes dynamic behaviour that (1) resets existing data,

???

> (2) bypasses NOT NULL validation for updates and

???

> (3) makes the value of the defaulted field a moving target. 
> 
???

> Who needs or wants that?  If that dynamic behaviour is wanted, we have triggers.
> 
I can't say, because I don't understand any of your questions.

> What we *really* need is to address the update of existing records in situations where (a) a nullable column is ALTERed to a domain that is not nullable

Already done.

> and (b) a new, non-nullable column is added.
> 
What's being discussed here.


Adriano