Add value traversal methods to Type

[findepi]

#12795 introduces some awesome value traversal utilities in Iceberg connector.
This PR makes them available to everyone.

[findepi]

Relates to #3316

[findepi]

@martint @losipiuk @sopel39 @rzeyde-varada @raunaqmorarka
what do you think about general direction?
Let's have agreement before i spend more time on this.

If we don't want to add this to Type, we just can keep having the value traversal code within Iceberg plugin.

[losipiuk]

I like the interface. The other option to model that would be a new operator. But then it would be hard to consume that in the Iceberg connector - which is the sole use for now.

[findepi]

thanks @losipiuk

@martint @sopel39 @rzeyde-varada @raunaqmorarka thoughts?

[raunaqmorarka]

thanks @losipiuk

@martint @sopel39 @rzeyde-varada @raunaqmorarka thoughts?

The new API lgtm, we should be able to use it in #3316 to find adjacent value and then use existing methods for equality check with adjacent value for implementing areConsecutive

[findepi]

@martint thoughts?

[findepi]

apparently not useful, hence maybe no thoughts.

[findepi]

Needed for #14452

[losipiuk]

I liked it before. Stil like it.

[findepi]

(just rebased on current state of #14747)

[martint]

It can't match getJavaType. For types such as smallint, integer, bigint, getJavaType returns long.class. This method takes an Object, so it doesn't support primitive values (they would need to be boxed).

In general, I'm not sure I like how this method tries to be generic for all types but:

• It's only supported for orderable types
• The signature is not tight enough to represent all carrier types safely.

[findepi]

It can't match getJavaType. For types such as smallint, integer, bigint, getJavaType returns long.class. This method takes an Object, so it doesn't support primitive values (they would need to be boxed).

yes, I meant boxing here

btw this is modeled like we did for getRange in e23e317#diff-3eedf5cda66ac7a68eb48f4eee146a4ccf5658fd07436ba5b279a089294a5c0cR174

It's only supported for orderable types

yes, same as getRange
non-orderable types will remove Optional.empty() since there is no "next" nor "previous"

The signature is not tight enough to represent all carrier types safely.

this part i did not understand.
@martint can you please clarify?

[findepi]

Added value traversal for few more types, so that Iceberg-side of things is fully redundant.
While Iceberg is the only use-place for now, this gonna be used in #14452 too.

[findepi]

@losipiuk @martint PTAL

[findepi]

CI #14441