Re: setNull() and =?

[Bernard <bht@xxxxxxxxxxxxx>]

Silvio,

You hit the nail on the head.

Just kepp hitting it again and again.

Why should application developers carry the burden of this "purity",
meaning this hairsplitting detail which is not even supported? Clearly
the driver should know how when to use "IS" or "=".


So why do I think it is not supported?

For the sake of purity, let's accept that there is a difference in
logic between:

a) NULL representing the state of a missing value or in other words
implicating a timeline

and

b) NULL representing a special value meaning that it cannot and must
not be supplied implicating that this is final and there is no
timeline and maybe this NULL value partly identifies a row.

Then the engine or the driver should apply its logic depending on
these cases, which should be either evident from the data of a query
or, in case of tables, derived from an additional attribute of the DDL
for the corresponding field that controls which type of NULL treatment
a) or b) should be applied.

Imagine a DISTINCT on a query result - do you want or don't you want
to repeat rows that are equal except a single column that has NULLs in
it? Clearly there are 2 possible cases.

Currently it appears that only case a) is considered by most engines
which is only one side of the coin. To me this single-sided support
for the less intuitive option somehow smells like political
correctness for the sake of it.

So all this "purity" is not helping developers, because, due to the
lack of full depth implementation in SQL, it's messy.

Full-depth implementation would make things a lot simpler and last not
least, pure.

Finally, purity would not have to be explained anymore.


Bernard


On Wed, 7 May 2003 00:14:40 +0200, you wrote:

>The fact that Expression = null never succeeds in SQL is very plausible but
>serves little practical use. Especially in the context of a prepared
>statement having a Expression = ? evaluate to true when the corresponding
>paramater is set to null makes a lot of sense. Doing it the way it is done
>now (and all major databases I know of do) requires two prepared statements
>in eacht situation where a null value is possible.
>
>It is a pitty that this behaviour appears the current consensus.
>
>Silvio Bierman
>
>
>
>---------------------------------------------------------------
>Mckoi SQL Database mailing list  http://www.mckoi.com/database/
>To unsubscribe, send a message to mckoidb-unsubscribe@mckoi.com