This can’t be correct.

At least in Rust, null (or None) is not treated at all like how databases treat it. If you have T: PartialEq<T>, then there’s an implementation for Option<T>: PartialEq<Option<T>>.

With this implementation, None == None. The result is true. None != None is false.

In an SQL database, (null = null) is null. Neither true nor false. (null != null) is also null. Neither true nor false.

This is an enormous difference, and it is basically THE gotcha for working with null in SQL databases.

If you want to translate that into a "traditional" programming language, the closest I can give you is Haskell, where you can think of SQL equality as being normal equality lifted into the Maybe applicative functor. (If that doesn’t make sense, you’re not a Haskell programmer, don’t worry about it.)

    sqlEq :: (Applicative f, Eq a) => f a -> f a -> f Bool
    sqlEq = liftA2 (==)

This has a generalization of the tri-value semantics.

    > Nothing `sqlEq` Nothing
    Nothing
    > Nothing `sqlEq` Just 4
    Nothing
    > Just 4 `sqlEq` Just 5
    Just False
    > Just 4 `sqlEq` Just 4
    Just True

I say “generalization” because this works in any applicative functor.