For what it is worth, I think the question of whether null == null is only meaningful in the context of a specific type system, which Gremlin so far does not provide. My personal preference is to avoid SQL-style nulls and achieve optionality through union types (e.g. Java's Optional or Haskell's Maybe). In the case of two lists, if you can assume that the type of the list is list<optional<int>>, then you can safely treat null like Optional.empty(), and compare it with another null of the same logical type (int). If that is the interpretation of your two lists, then the intersection is [1, null].
Josh On Tue, Aug 1, 2023 at 5:47 PM Ken Hu <k...@bitquilltech.com.invalid> wrote: > Hi All, > > As Gremlin evolves and gains more functionality, it is important that we > establish some fundamental rules to provide consistency in results. One > such question that we should come to agreement on is how null values are > compared. Currently, Gremlin seems to mostly follow the comparison that is > used in Java where NULL == NULL returns TRUE. However, in many other > database systems, NULL == NULL would return FALSE (or NULL). > > This question comes about as I'm starting to look a little deeper into the > proposed list functions. An example of where this is applicable is the > INTERSECT list function. For example, if you have a list, A, which is > [1,2,null] and a list, B, which is [1,null]. Should the result of an > INTERSECT be [1,null] or [1]? > > I think it makes sense in Gremlin for us to follow the rule that most > programming languages follow which is the former (NULL == NULL returns > TRUE) because it feels more in line with how Gremlin was meant to be used > (together with your code rather than as a string query). In this case the > return value would be [1,null]. > > What are your thoughts on this subject? > > Thanks, > Ken >
