--- In firebird-support@yahoogroups.com, Christian Danner wrote:

> But why not generally permit the expression 'null is null' as a
> comparison, when '1 is null' (e.g. in a 'select case' statement) is
> allowed and interpreted as 'false'. Shouldn't 'Unknown is Unknown'
> be a legitimate question and answered with 'true'?

If 'Unknown' was a value rather than a state, I would agree. But I
consider this

[<variable> | <constant>] is null

and if someone asked me:

"Tell me if the answer to my unknown question is unknown to you", then
I would answer "I don't know". If the question was: "Tell me if the
square root of -1 is unknown to you", I would answer yes, but if it
was "Tell me if the square root of 4 is unknown to you", I would
answer no. So to me it isn't that obvious that NULL IS NULL should
return true...

Set

> >If so I wouldn't regard it as future proof
> >behaviour because parameters are substitutable values not a random
> >string to be inserted at runtime.
>
> Shouldn't we differentiate between named parameters as a client side
> feature, translated into the positional XSQLVAR fields in order to do
> the api call, and (named) parameters/variables within sps, which might
> be wholly different things in further interpretation and processing -
> PSQL vs. DSQL.
>
> >You may find a future version breaks
> >this behaviour.
>
> Now you rattled me.
>
> Christian
>