Glen Parker wrote:
> Buy the same token, some application have no use whatsoever for the
> distinction between NULL and ''. In that case, the distinction just
> adds work.
True, I suppose. But if I need that, I can live with a one-time "...not
null default ''..." addition to my table definition. Or a
coalesce(mycolumn, '') if I only need the null to equal '' in specific
queries or views.
> I would love to see different ways to handle NULL implemented by the
> server. For what I do, NULL could always compare equal to zero and ''.
> I have no use for NULL in text values. I do need it for numerics,
> however it doesn't mean "unknown", it just means "not entered", which is
> different because I always treat it as zero.
If that works for your app, great. But in many (most?) cases it doesn't.
A survey, for example, might ask for age or income. Some people will
decline to answer one or both of those questions.
When someone asks for the average age of respondents, they want exactly
what avg() returns - the sum of the non-null ages divided by the count
of non-null ages. If the nulls were treated as zeros, the answer could
be severely skewed.
Cheers,
Steve