The semantics of NULL are well defined for us already in SQL standards. However, in the world of Geometry / Geography we have another entity which is not quite NULL nor quite fully defined: the empty geometry. Empty geometries can be created with things like intersection calls that have have no intersection, e.g. ST_Intersect('POINT(0 0)', 'POINT(1 1)') == POINT EMPTY. So, in the presence of empty, how should functions behave?

 * ST_Union(geometry, empty) == geometry
 * ST_Union(empty, empty) == empty
 * ST_Difference(geometry, empty) == geometry
 * ST_Difference(empty, geometry) == empty
 * ST_Distance(geometry, empty) == NULL
 * ST_DWithin(geometry, empty, tolerance) == FALSE
 * ST_Contains(geometry, empty) == FALSE
 * ??? ST_Contains(empty, empty) == FALSE
 * ST_Intersects(geometry, empty) == FALSE
 * ??? ST_Intersects(empty, empty) == FALSE
 * ??? ST_Disjoint(empty, empty) == FALSE
 * ??? ST_Disjoint(geometry, empty) == FALSE
 * ST_IsSimple(empty) == TRUE
 * ST_IsValid(empty) == TRUE

''Note:''
It might make sense to try to maintain the geometric truisms when specifying the semantics around ''empty'' - ie. things like:

 * intersects( A, B ) => !disjoint( A, B )
 * A == B => intersects( A, B )
 * contains( A, B ) && contains( B, A ) => A == B

If we don't maintain these we will probably need to complicate logical comparisons with special cases for ''empty'' - it may be the case that this is necessary, but it would be nice if it just 'came out in the wash'.

This suggests to me that perhaps:

 * ST_Intersects( empty, empty ) == TRUE
 * ST_Disjoint( empty, empty ) == FALSE
 * ST_Distance( empty, empty) == 0
 * ST_DWithin( empty, empty, tolerance) == true