db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6834) support for CURRENT_TIMESTAMP(precision) appears to be missing
Date Sun, 13 Sep 2015 15:09:45 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742507#comment-14742507

Rick Hillegas commented on DERBY-6834:

Note that CURRENT_TIME has the same optional precision argument, according to the Standard.
If we improve one, then I think that we should improve the other.

The 2011 SQL Standard, part 2, section 6.32 (datetime value function) has this to say about
the bounds and default for time and timestamp precisions:

SR 34) "If timePrecision is not specified, then 0 (zero) is implicit. If timestampPrecision
is not specified,
then 6 is implicit."

SR 36) "The maximum value of timePrecision and the maximum value of timestampPrecision shall
be the same implementation-defined value that is not less than 6. The values of timePrecision
and timestampPrecision shall not be greater than that maximum value."

Derby violates SR 34 because the timestamp precision of System.currrentTimeMillis() is 3.
Changing this to 6 would create a backward compatibility issue. Maybe it's a minor incompatibility
since we are increasing the precision rather than decreasing it.

We can't conform completely because these rules say that CURRENT_TIME and CURRENT_TIMESTAMP
must have the same maximum precision and that precision must be at least microseconds. But
a Derby TIME value is an instance of  java.sql.Time, which has millisecond precision.

If we pursue this enhancement, then I think that we should allow CURRENT_TIME and CURRENT_TIMESTAMP
to have different maximum precisions, the maximum precison of CURRENT_TIMESTAMP should be
9 (the precision of System.nanoTime()), and we should raise an error if the user specifies
a precision which is out of bounds.

Other thoughts?


To conform to SR 36, we would need to raise an error if timestampPrecision is greater than

> support for CURRENT_TIMESTAMP(precision) appears to be missing
> --------------------------------------------------------------
>                 Key: DERBY-6834
>                 URL: https://issues.apache.org/jira/browse/DERBY-6834
>             Project: Derby
>          Issue Type: Improvement
>            Reporter: Julian Reschke
>         Attachments: firstTry.diff
> See <http://savage.net.au/SQL/sql-92.bnf.html#current%20timestamp%20value%20function>,
<http://www.h2database.com/html/functions.html#current_timestamp>, <http://www.postgresql.org/docs/8.2/static/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT>

This message was sent by Atlassian JIRA

View raw message