Hi Milan,

I was trying to be more generic that specifying particular
libraries. By "interfaces" I mean any database interface,
regardless of what library you may use to create it. Given
any of the libraries that I know of it is possible to have
the problem or avoid the problem at the cost of performance.
The point being that performance can be an issue with the
behaviour of standard SQL DEFAULTs.

You seem to be under the impression that I want to change the
behaviour of defaults. Go back to my original posting (not
just the reply to Jim) and you will see that what I want is
a new variation of DEFAULT behaviour. Something that does
not change existing databases, but allows new databases to
be created that can avoid this problem - and to also allow
the other advantages I describe to be realised.

If distinguishing the difference between a value that has not
been specified (NULL) and an empty value (0 or blank) is
important to a particular field then you would not use this
new feature (eg: dates, FKs, blobs).

If I want to write my code in the simple form that does not
consider NULL in certain columns, then I must ensure that
the database does not allow NULL in those columns. Thus the
NOT NULL contraint is required on the columns. If I want a
consistent default values to be applied then I must:

- set such default values from each and every application
interface to that data
or
- write triggers to enforce it
or
- I must accept the performance hit of repreparing every
insert to be sure only supplied values are sent

Of these only the trigger option is really appropriate, and
that means lots and lots of code. A new type of default
declaration could avoid this.

> Well, I guess it's just your POV. In all my applications I
> don't have a single BEFORE/AFTER UPDATE trigger. I do have
> many on insert and delete operations, but none of them
> addresses this issue.

Thats fine. I dont expect that everyone would want to use the
new feature, but equally I am fairly certain I am not the only
one that would welcome some way to reduce the complications
involved in handling NULL where it is not relevant to the
application.

I dont want to eliminate NULL from my applications, I just want
to reduce its impact. Have NULL as a concern only where it is
relevant - instead of the current situation where NULL must be
considered with every column.

--
Geoff Worboys
Telesis Computing