According to Date you should never use NULLs. This is because a NULL can
mean many different things. It can mean not known (e.g. I know he has an
age but I don't know what it is), It can be not applicable (e.g. in a
Party table of organizations and people, people would be of a certain sex
but an organization would not), It can mean a number divided by zero, It
can also mean I don't know if the value is unknown or if the value is not
applicable etc. etc. In Date's view there is an infinite number of
meanings for null and for a database to handle it correctly would require
an equivalent set of operators for each type of null.
I think though that Nulls are a very useful feature of SQL databases. It's
just that when I write a program, I have to know in a particular context
what a null means and handle it appropriately (of course controlling nulls
in an index is a different matter). I don't think there is only one
accepted way to use nulls.
> Roman Neuhauser wrote:
>> # [EMAIL PROTECTED] / 2005-01-20 01:35:32 +1100:
>>
>>>i have a unique index on a table over multiple columns. If now one of
>>>the records has a null value in one of the indexed columns i can insert
>>>the same record multiple times.
>>>
>>>Is this a problem within postgres or expected?
>>
>>
>> In SQL, NULL means "unknown value". How could you assert that two
>> NULLs are equal?
>>
> which doesn't make mathematical sense.
> mathwise null is an empty result.
> so setting the logic up using the math logic, null values are always
> equal.
>
> --
> ========================================
>
> only plain text format email accepted.
>
> smaller file size, no virus transfer
> no proprietary file formats.
>
> ========================================
>
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
