trinodb/trino

INTERVAL `x` SECOND values with `x` having >3 digits of decimal precision are silently truncated

Open

#6,754 opened on Jan 29, 2021

View on GitHub
 (4 comments) (0 reactions) (0 assignees)Java (2,678 forks)batch import
good first issue

Repository metrics

Stars
 (9,113 stars)
PR merge metrics
 (Avg merge 5d 9h) (306 merged PRs in 30d)

Description

minimal example:

presto:default> 
SELECT val + INTERVAL '.0001' second 
FROM (VALUES TIMESTAMP '2021-01-01 00:00:00.123456789 UTC') 
AS t (val);
               _col0
-----------------------------------
 2021-01-01 00:00:00.123456789 UTC
(1 row)

This is a really unfortunate bug as it results in silently incorrect data. Ideally the INTERVAL function could be patched to do the right thing here, but we'd also be ok if it would at least throw an error rather than return incorrect data.

Contributor guide

Research direction
Examine the INTERVAL parsing logic in Trino's SQL parser and type coercion to find where decimal seconds are truncated. Look for how the literal `.0001` seconds is converted to a Duration or IntervalDayTime type, and identify where precision beyond 3 decimal places is lost.
Tech stack
java
Domain
databasebackend
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
Half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
JavaSQL
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40