Simplify and clean up data skipping logic a bit

[scovich]

Several cleanups to the data skipping logic (partly inspired by recently added parquet stats skipping logic):

• Reorder Expression match arms to match declaration order
• Add an inverted flag to the data skipping expression logic, which allows to more easily push NOT down
  • Remove as_inverted_data_skipping_predicate (no longer needed)
  • Collapse the four {tight, wide} x {null, not null} helper methods into just tight and wide helpers
• Add support for boolean literals and columns
  • They don't necessarily have good skipping power, but defaulting them to NULL can disable skipping
  • i.e. FALSE OR <expr> and <col> OR <expr> no longer blocks data skipping on <expr>
• No longer create new expressions that need to be passed to as_data_skipping_predicate (e.g. Equal comparison)
• Make NotEqual data skipping logic a bit easier to grok

[nicklan]

Nice, thanks! One small nit, but lgtm

[nicklan]

nit: This isn't really an invalid operation, it's just that we expected to have matched above, so maybe:

Suggested change

	In | NotIn => return Err(Error::generic("Invalid expression given")),
	In | NotIn => return Err(Error::internal("Encountered In/NotIn in general BinaryOperation match")),

[nicklan]

Actually, I think there is one issue.

[nicklan]

This causes an error if the column isn't a boolean column, even if it could be coerced to a boolean.

So a query that might work:

SELECT * FROM foo WHERE int_col

will cause kernel to error.

Not sure what the best course of action is wrt. to doing coercion in our expression eval, checking if the col is bool here, or just giving up on col expressions for now.

This is actually why the test for expression:

            Expression::column("number").and(empty_struct.clone().is_null()),

is failing.

Thoughts?

[scovich]

Expression framework docs are very clear that kernel always expects exact type matches, and that engine is responsible to apply any casting or coercion that should happen. Granted, we don't currently provide a cast expression, so that could be difficult to do in practice.

I guess the real question is -- is kernel responsible to prevent/swallow all query errors that might result from a data skipping predicate that was derived from a syntactically incorrect WHERE clause the engine gave it?

[nicklan]

So we would expect that if the engine sees the user has written WHERE int_col it would rewrite that as WHERE (cast int_col as boolean) and then give that to kernel (which as you mention is hard given we don't have a cast)?

[scovich]

Potentially superseded by #420