[SPARK-3412] [SQL] Add 3 missing types for Row API

[chenghao-intel]

BinaryType, DecimalType and TimestampType are missing in the Row API.

[chenghao-intel]

test this please.

[chenghao-intel]

test this please.

[SparkQA]

QA tests have started for PR 2284 at commit 3644ffa.

• This patch merges cleanly.

[SparkQA]

QA tests have finished for PR 2284 at commit 3644ffa.

• This patch fails unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[marmbrus]

I'm not sure we want to do this. The specific getters / setters are really only so that we can avoid boxing primitives. We added getString mostly because at one point we were considering having some kind of internal mutable backing data structure here for performance (and we still might).

What do you think about something like def getAs[T](i: Int): T = apply(i).asInstanceOf[T] in Row?

/cc @liancheng @rxin

[liancheng]

@marmbrus I vote for getAs[T](i: Int).

@chenghao-intel As Michael has just said, avoiding boxing cost is the major design rationale behind these setters/getters. Unfortunately, we haven't fully leverage this design and boxing still happens on some critical paths, for example, building/accessing in-memory columnar buffers. PR #2327 is an attempt to (partially) solve this problem.

[rxin]

Yea getAs[T] sounds good.

[chenghao-intel]

Thank you guys for the explanation and voting, the boxing/unboxing is quite annoy problem for performance. But from the normal developer point of view, the Row api is the key to interact with the SparkSQL, complete data type (11 primitive data types currently) support (for getter / setter) may make more sense for people.

And if we used the generic type here, people may confused what the scala/java object type is if the data type is TimeStampType specified via schema, and even they probably add an object of java.security.Timestamp for the data type TimestampType.

Sorry, probably I missed some of the original discussions for row API design.

[marmbrus]

The type for each SQL type are pretty well documented in the programming guide (updated for 1.1 to be published soon). It seems unscalable to add new methods to all the various row implementations for each new datatype, especially since all they are doing is casting. Given this I propose we close this issue.

[chenghao-intel]

ok, I am closing it.