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

[Helen B. <he...@tp...>]

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.

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 and (b) a new, non-nullable column is added.

Helen