"Lifting" in this context essentially refers to extending a function defined on certain domain of values, say X, to a domain X' which "includes" (air quotes because see below) all the values in X and some representation of a missing value from the domain X. The extended function should derive its behavior from the original function in some systematic way.

More concretely: suppose we have functionality `f` defined over a domain of objects of type `T` -- that is, we're given a method `f(x::T)`. In this case, the domain X is the set of all values of type `T`. The extended set X' is the set of all values of type `Nullable{T}`, where `Nullable{T}` is a specialized container type that can contain precisely zero or one values (an empty `Nullable{T}` object represents a missing value of type `T`, at least for our purposes). I quoted "includes" above because technically the domain of values of type `Nullable{T}` doesn't strictly include values of type `T` (the original domain X), but it includes a set of values that is "isomorphic" in some loose sense to this X. Lifting `f` over `Nullable{T}` arguments means systematically deriving some behavior for `f(x::Nullable{T})` from the original behavior `f(x::T)`. The standard semantics for this are to return `Nullable(f(x.value))` if `x` is null and return an empty `Nullable{U}` if `x` is null, where `U` depends somehow on `f` and `T`.

It's worth noting that the solution to lifting adopted in SQ does not automatically give lifted behavior to `f(x::Nullable{T})` when the latter is invoked outside of a querying macro.

So when called with null for a required parameter, return a null result directly instead of calling the lifted function.

So, if x is NULL return NULL, otherwise f(x)?

In short, yep. For most f. Sometimes we want to do something different, as in three-valued logic.

Okay, thanks for explaining all of this.