Support verifying SELECT queries with DATE or UNKNOWN columns

[caithagoras]

== RELEASE NOTES ==

Verifier Changes
* Add support for verifying ``SELECT`` queries that produce ``DATE`` or ``UNKNOWN`` (null) columns.

[mbasmanova]

@caithagoras What is UNKNOWN column and what are the queries that return no results?

[mbasmanova]

@caithagoras Improve JdbcPrestoAction commit looks good, but would you given an example of query with no result?

[mbasmanova]

typos in the commit message; also, commit message explains how date columns are supported, but doesn't explain how other types (unknown) are supported. Also, what is "unknown" column type?

Support verifying SELECT queries with date columns

SELECT query is rewritten into CreateTableAsSelect so that results of control 
and test queries can be saved into temporary tables before comparing the 
checksums. However, certain columns types, such as date and unknown as well
as complex types (lists, maps and structs) containing those types cannot be written
into a Hive table.

Previously, SELECT queries that generate date columns were skipped 
(the control query would fail). This change supports verifying those queries by 
casting each date column into a timestamp column.

[mbasmanova]

This logic is Hive-specific. Does Verifier support only Hive connector?

[caithagoras]

This is the assumption so far. Verifier are unaware about what connector is associated with a given catalog, so it won't be able make decisions around that as well.

[mbasmanova]

@caithagoras I believe same problem applies to Geometry type. CC: @jagill

[caithagoras]

@mbasmanova A Presto unknown type corresponds to a Hive void type, whose value can only be null. For example, SELECT null produces a column of unknown type.

Although being able to verify unknown column is trivial (they always matches), a query may have a mixture of unknown columns and normal columns, and it's better if we verify those queries than skipping them. There are a number of reasons why people want so select multiple null columns: query might be generated, results may be consumed by a script, and so on.

In additional to supporting DATE and UNKNOWN, we'll also be able to support structured type with DATE and UNKNOWN, and I'll do that in a separate PR.

[mbasmanova]

@caithagoras Thanks for explaining. I understand now what is top-level UNKNOWN column, but I'm still puzzled at how list, map, struct may include a field of type UNKNOWN. Would you clarify?

[caithagoras]

@mbasmanova This is similar with structured type. If array elements are statically null, the element type is unknown, and the array type is array(unknown), which cannot be written into Hive.

explain select array[null, null]
- Output[_col0] => [expr:array(unknown)]

explain select map(array[1], array[null])
- Output[_col0] => [map:map(integer, unknown)]

explain select row(null)
- Output[_col0] => [expr:row(unknown)]

[mbasmanova]

@caithagoras Thank you so much for clarifying.

[caithagoras]

@mbasmanova Regd Improve JdbcPrestoAction:

When we run a Presto query using jdbc, INSERT INTO query does not have a ResultSet, that is, PrestoStatement.getResultSet returns null, and getUpdateCount returns the number of rows inserted. I haven't checked other query types but I think CREATE TABLE AS should be similar.

Maybe "no result" is not a good wording, as "ignore result" is closer to what is done there.
JdbcPrestoAction provides 2 methods, one that takes ResultSetConverter and returns a QueryResult, and the other does not takes a converter and returns a QueryStats. If caller does not provide a converter, the query will be executed, but the result will be ignored even if the query is a result-producing query.

We do not need results from setup, main, and teardown queries, and we do need results from rewrite, desc, and checksum queries, etc.