It makes no sense, because non-nullable columns can have NULL value.
E.g. in "foo LEFT JOIN bar ON condition", the non-nullable columns of "bar"
when it has no row matching "condition".
Even when we are about to insert/update a row, we should not put a
hard-coded value (that just happens to be the one constructed by the
C++ default constructor for that type) in non-nullable columns: there
is no guarantee that this value makes sense in that database's context.
The database may or may not have a default value set for that column.
If it has, we should leave it up to the database to set it automatically.
If it has not, an error *is* the right reaction.
Another place where this substitution does damage is when we refresh a
row. We use the values we have read from the primary key to select the
row again. So we should not mangle those, else the select returns no
row and we mistakingly think the row has been deleted.
a261e36481