Hello,

     I discovered that when a field is added to a table with a NOT NULL 
constraint and a default value, it is automatically filled with that 
default value. Example:

alter table table1 add field1 integer default 1 not null;
commit;
select distinct field1 from table1;

FIELD1
========
        1

Nevertheless, when I applied this DDL statement on a production table, 
with concurrent connections, one record wasn't filled with its default 
value, but remained NULL.
I discovered this, days after, when I tested a restore from a backup and 
the restore process was aborted because of a constraint validation error.

My questions are the following:

1) Is the intended effect to fill behind the scenes a newly created 
field with its default value when there is a not null constraint ?
2) Could this behind the scenes filling fail because of an update or 
insert of another concurrent transaction ?

Thanks
Aldo




Reply via email to