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