Pushing down 'not equal' to predicate

[akuzin1]

Description of changes:
Modified statement that is responsible for adding IS NOT NULL clause to generate sql for JDBC connectors.
Prior to change, when evaluating a not equal to predicate it would short circuit and not push down all predicates to sql statement.
For Example:
SELECT * FROM item WHERE i_manufact_id <> 138
Would be translated to:
SELECT * FROM item WHERE (i_manufact_id IS NOT NULL)

This is the result of calling getSpan() on SortedRangeSet, which returns a Range that is a summary of the lowest lower bound and the highest upper bound that represents this ValueSet.

Therefore, the following ValueSet from statement with i_manufact_id <> 138 predicate:

        i_manufact_id=SortedRangeSet{
            type=Int(64, true), nullAllowed=false, lowIndexedRanges={
                Marker{
                   valueBlock=Int(64, true), nullValue=true, valueBlock=true, bound=ABOVE
                   }=Range{
                        low=Marker{
                            valueBlock=Int(64, true), nullValue=true, valueBlock=true, bound=ABOVE
                           }, 
                        high=Marker{
                            valueBlock=Int(64, true), nullValue=false, valueBlock=138, bound=BELOW
                        }
                   }, 
                Marker{
                   valueBlock=Int(64, true), nullValue=false, valueBlock=138, bound=ABOVE
                   }=Range{
                        low=Marker{
                            valueBlock=Int(64, true), nullValue=false, valueBlock=138, bound=ABOVE
                        }, 
                        high=Marker{
                            valueBlock=Int(64, true), nullValue=true, valueBlock=true, bound=BELOW
                        }
                   }
               }
           }
       }

and the following ValueSet from statement with i_manufact_id IS NOT NULL predicate:

i_manufact_id=SortedRangeSet{
            type=Int(64, true), nullAllowed=false, lowIndexedRanges={
                Marker{
                    valueBlock=Int(64, true), nullValue=true, valueBlock=true, bound=ABOVE
                }
                =Range{
                    low=Marker{
                        valueBlock=Int(64, true), nullValue=true, valueBlock=true, bound=ABOVE
                    }, 
                    high=Marker{
                        valueBlock=Int(64, true), nullValue=true, valueBlock=true, bound=BELOW
                    }
                }
           }
        }

evaluate to the same Range when called getSpan on and they exit at the same condition.

According to ANSI SQL standards, when assessing a predicate comparison involving a NULL value, it does not yield true or false outcomes and is consequently excluded from the result set. This means that if there is more than one comparison operator performed on a single column, it will automatically drop NULL values, so IS NOT NULL only needs to be pushed down if it that's the only one.

So for example, in the following statement:
SELECT * FROM item WHERE i_manufact_id <> 138 AND i_manufact_id IS NOT NULL
the latter part will be inherently be achieved by pushing down first part.

The change results in 'IS NOT NULL' predicate only being pushed down if there's one Range present in ValueSet.

Generated SQL After Change:
SELECT * FROM item WHERE ((i_manufact_id < 138) OR (i_manufact_id > 138))

Testing:
Because JdbcSplitQueryBuilder is an abstract class and can't be initialized, I added unit tests to the MySqlQueryStringBuilder to verify proper behavior for generated SQL string, when predicates != and IS NOT NULL are being used.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[burhan94]

can we add some test cases for this pls?

[hackett123]

nit, you can init and add the map values in one line using ImmutableMap.of(key, value, key2, value2, ...).

It's generally cleaner to avoid initing a collection and later adding or modifying it (called the init-then-modify antipattern). This here isn't maybe only a violation of it from a purists perspective, but you can imagine how it can lead to cleaner code. so this comment applies to both tests in this file