>
> I'm somewhat against such a configuration. This being a server-side
> configuration results in Kudu deployments in different environments having
> different sets of available types, which seems very difficult for
> downstream users to deal with.
Yeah I agree. I am not super into the idea.
Thank you for the feedback. Below are some responses.
Do we have a compatible SQL type to map this to in Spark SQL, Impala,
> Presto, etc? What type would we map to in Java?
In Java we would Map to a BigInteger. Their isn't a perfectly natural
mapping for SQL that I know of. It has been
I think it would be useful. As far as I've seen the main costs in carrying
data types are in writing performant encoders, and updating integrations to
work with them. I'm guessing with 128 bit integers there would be some
integrations that can't or won't support it, which might be a cause for
Hi all,
As a part of adding DECIMAL support to Kudu it was necessary to add
internal support for 128 bit integers. Taking that one step further and
supporting public columns and APIs for 128 bit integers would not be too
much additional work. However, I wanted to gauge the interest from the
