[
https://issues.apache.org/jira/browse/CALCITE-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601687#comment-17601687
]
Julian Hyde commented on CALCITE-5266:
--------------------------------------
For the internal representation (i.e. rows flowing through enumerable
operators) I think we should stick to numerics. Two reasons:
* the java.time classes have quite a lot of overhead (time and space);
* the semantics of SQL TIMESTAMP are LocalDateTime, not Instant; using Instant
is a recipe for confusion.
I suspect that a SQL {{TIMESTAMP(9)}} value (i.e. nanosecond precision) would
require more than 64 bits, and of course Java's largest primitive is a 64-bit
integer. So my ideal representation would be the same as for
{{DECIMAL(precision, scale)}} with arbitrary fixed values of precision and
scale. Because they are fixed for any particular column, we do not need to
store them for each value. A low-overhead implementation might be
{{{}byte[]{}}}. {{BigInteger}} has a {{byte[]}} constructor, so we can convert
to {{BigInteger}} and then to {{BigDecimal}} if we need to do arithmetic.
> Increase precision of TIMESTAMP, INTERVAL types to microseconds, nanoseconds
> ----------------------------------------------------------------------------
>
> Key: CALCITE-5266
> URL: https://issues.apache.org/jira/browse/CALCITE-5266
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Dmitry Sysolyatin
> Priority: Major
>
> TIMESTAMP, INTERVAL types can preserve only milliseconds, because internal
> TIMESTAMP representation is Long. But it would be good to extend precision to
> microseconds and nanoseconds.
> I suggest to use standard java.time classes for representing TIMESTAMP and
> INTERVAL type internally:
> # TIMESTAMP type can be represent like java.time.Instant
> # INTERVAL type can be represent like java.time.Period + java.time.Duration
> What do you guys think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
