Add support for varchar to timestamp coercer in hive tables

[Praveen2112]

Description

Add support for varchar to timestamp coercer in hive tables. In case of partitioned table it is supported by most of the format and in case of unpartitioned tables only ORC format is supported as of now.

The coercion that was supported as of current master for unpartitioned tables are inherently supported by the ColumnReader and this PR introduces a framework which maps a OrcTypeKind to a corresponding TrinoType and also re-uses the TypeCoercer used by partitioned tables. In case of invalid String we append null instead of failing

Additional context and related issues

This is on top of #16869

Release notes

( ) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
(x) Release notes are required, with the following suggested text:

# Section
* Add support for vachar to timestamp coercer in hive tables

[findepi]

let's finish #16869 first.

[Praveen2112]

@findepi #16869 was finished so this is ready for a new round of review

[huberty89]

LGTM

[findepi]

.orElse(VARCHAR);

[findepi]

it looks like we could always use VARCHAR here.
i don't think fromOrcType.getLength() matters.

[Praveen2112]

What if the schema of a column changes from unbounded varchar to a bounded varchar and them to timestamp, won't it affect the result ?

[Praveen2112]

I don't have a test coverage for this - but when we try to append data to an existing ORC file - the footer could capture the new schema

[findepi]

i thought this is being used on read, not on write?

also, i think orc files are immutable, you cannot append to an existing data file

[findepi]

insert-only tables mean that you can insert to them, but you cannot update, delete from them
this is a hive concept

yes, i vaguely remember some mention of some streaming-ingest for ORC where files are built incrementally, but Trino does not do that and will never do that. Object storage doesn't support that either.

[Praveen2112]

Okay !! We can assume that - varchar length specified in the footer will be in always greater than or equal to the length of Slice in case of VariableWidthBlock i.e we won't require a truncating of varchar during reads.

[Praveen2112]

I'll remove this code related to fromOrcType.getLength()

[findepi]

will this also obsolete Capture OrcType in OrcColumn commit?

[Praveen2112]

Yes !! So we will remove that commit.

[findepi]

add cases with micros and nano precision,
.123499
.123500
.123501
.123499999
.123500000
.123500001

[Praveen2112]

But these cases cannot be applied at the same time right ?

[findepi]

i don't understand the question.
do you mean we're limited to just one test data point?

[Praveen2112]

The existing test we have is limited to run with a default precision - I'll try to add additional test coverage by having a dedicated table wit varying precision or we could try be setting the default precision to NANO_SECONDS

[findepi]

good point. we should probably exercise this logic with all supported precisions
let's have a dedicated test

[Praveen2112]

@findepi Squashed the commits - and one major change we did is that - we used Timestamp.valueOf to parse the String instead of using a DateTimeFormatter - the orc version reference I took was a recent one while hive 3.1.3-rc uses java.sql.Timestamp - Ref : https://github.com/apache/orc/blob/2880540d8caf18ccbbe3442fca47be150116a235/java/core/src/java/org/apache/orc/impl/ConvertTreeReaderFactory.java#L231

[findepi]

the orc version reference I took was a recent one while hive 3.1.3-rc uses java.sql.Timestamp - Ref :

Does this mean we have to choose which Hive version we're going to be compatible with?

[Praveen2112]

For a few edge cases - it is dependent on the hive version or future versions

[Praveen2112]

Due to this #17604, Ill have to rebase this PR to the different base. Sorry for the inconvenience