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

[Vlad K. <hv...@us...>]

> I'm implementing what's described in subj. Now, user can already do this, but it's not good.

    Not sure i understand - what is not good ?
 
> When engine reads a NOT NULL field with a DEFAULT, it executed the DEFAULT expression and returns a value.
> 
> For CURRENT_DATE/TIME/TIMESTAMP expressions, it returns the "0 value", with for dates means 1858-11-17. 

    Hmm, do you know why it returns 0 ? According to the said above it should evaluate expression
at time of reading record (also not perfect, but better than return zero). Looks like a bug.

> Only simple expressions are allowed for DEFAULT now, with means more problems if complex expressions are allowed.

    Is standard allow to reference fileds from the same table in default expression ?
 
> Initial verification to implement the thing in a good way has to populate the fields in DFW, after the new format has 
> been created. This does not solve the problem completely. There can be snapshot transactions that see the new 
> field but can't see its default value.

    It is performance killer "solution" and i don't like it very much.

> Related to above, I tried to update records in system transaction. Initially works in some condition, but I don't 
> think it's good way to go either.

    Don't do it. System transaction should be read-only.

> So I think on an alternate way. At field creation time, its default value may be written in RDB$FORMATS. When 
> reading a NOT NULL field with a DEFAULT, the value written in the format version of the record is returned. This 
> may solve the problem of complex expressions, the problem of transaction visibility, and don't need an update on 
> the whole table. I've no code to prove this, it's just an idea.

    Sounds not bad but will not work if complex expressions referencing another fields from the same
table is allowed by standard.

Regards,
Vlad