Implement day-time intervals and current timestamp value function by hazefully · Pull Request #4645 · FoundationDB/fdb-record-layer

hazefully · 2026-09-21T08:44:12Z

This PR adds SQL support for the datetime value function CURRENT_TIMESTAMP
and for day-time INTERVAL literals as described in the SQL standard.

With the changes included in this PR, a following query would be possible:

SELECT * FROM T1 WHERE timestamp > CURRENT_TIMESTAMP() - INTERVAL '10' DAY

This PR doesn't add dedicated TIMESTAMP or INTERVAL data types yet, which is covered by #4738, so both SQL constructs underneath return long values:

The timestamp value returned by CURRENT_TIMESTAMP is the number of milliseconds since the Unix epoch as a bigint/Type.TypeCode.LONG.
Intervals are a signed number of milliseconds as a bigint/Type.TypeCode.LONG, which can be negative to indicate a negative interval.

The new `CURRENT_TIMESTAMP` built-in function and value

The new CURRENT_TIMESTAMP built-in function added in this PR evaluates to a new CurrentTimestampValue, which always evaluates to the evaluation timestamp stored in the query's EvalutionContext. This ensures that multiple invocations of theCURRENT_TIMESTAMP function in a single query return the same value, and that a continued query is continued with the same evaluation timestamp. The evaluation timestamp is derived from the system clock (truncated to milliseconds) while normalizing the query, unless the connection option FIXED_EPOCH_TIMESTAMP_MILLIS_FOR_CURRENT_DATETIME_FUNCTIONS is set with a fixed timestamp to use for all current datetime value functions.

The CURRENT_TIMESTAMP function can also be used in INSERT queries, and they will insert the same value for all records inserted in a single query.

Interval literals

Interval literals are parsed during query parsing time (which means that interval literals can't use prepared statement parameters such as INTERVAL ? DAY TO SECOND). The parsing is done according to SQL standard rules, as detailed here, and only day-time intervals (i.e. INTERVAL ... DAY TO SECOND) are currently supported. New SQL error codes are added to handle different cases of invalid interval literals: INVALID_INTERVAL_FORMAT (22006) and INTERVAL_FIELD_OVERFLOW (22015). See the tests added in ParseHelpersTest.java for some test-cases outlining how the parsing works.

Queries with day-time interval literals are canonicalized to SELECT .... INTERVAL ? DAY TO SECOND before the plans are stored in the plan cache, and the parsed interval literal string is stored as a scalar literal. See AstNormalizerTests.java for tests that confirm this normalization works as expected.

Supported operations involving interval literals and datetime value functions

It is possible to add or subtract an interval from the return value of a date-time value function as shown in the example above, the current operations are supported:

CURRENT_TIMESTAMP - | + INTERVAL
INTERVAL + CURRENT_TIMESTAMP

These rules are encoded in the grammar defined in RelationalParser.g4 as the new rule datetimeIntervalMathExpression.

Documentation

The SQL docs are intentionally not updated in this PR, and they will be updated once dedicated data types for TIMESTAMP and INTERVAL values exist, which is tracked in #4738.

hatyo · 2026-10-14T10:34:11Z

+class CurrentTimestampValueTest {
+
+    @Test
+    void correlationsAreEmpty() {


These tests feel superfluous if I am honest. I am ok with removing these test file, up to you.

I only had them because of test gaps reported by team scale, but they are no longer needed and I replaced them with some basic tests that actually check the behaviour of the value.

hatyo · 2026-10-14T10:39:16Z

+        /**
+         * A fixed Unix epoch timestamp in milliseconds to use in current datetime value functions.
+         */
+        FIXED_EPOCH_TIMESTAMP_MILLIS_FOR_CURRENT_DATETIME_FUNCTIONS


It looks like this is mainly used for testing purposes to make tests with time more deterministic, is my understanding correct?
If so, I wonder if there is a better way for doing this that does not necessitate adding a new option that could be (ab)used in prod.

That is correct, I tried to think of other ways enable setting a fixed timestamp for testing other than options but I couldn't think of anything that is much better:

We can add a new class TestOnlyOptions and introduce a new method RelationalConnection.setTestOnlyOption so at least it is more obvious if the option is used from test code.

We can make this a special clause in the query (something like WITH FIXED TIMESTAMP <>), and add that to the QueryExecutionContext.

Or alternatively we can just remove this feature, if you think it doesn't buy us that much functionality (we should still be able to test everything we just won't be able to assert on the values of the timestamp column itself).

hatyo · 2026-10-14T10:49:09Z

    : aggregateWindowedFunction                                                   #aggregateFunctionCall // done (supported)
    | nonAggregateWindowedFunction                                                #nonAggregateFunctionCall // done
    | specificFunction                                                            #specificFunctionCall //
+    | datetimeValueFunction                                                       #datetimeValueFunctionCall // done


Is there a specific reason for moving the #dataTypeFunctionCall branch in specificFunction rule to a specific rule here?

Both representations are ok, but I find the previous representation more concise honestly. The functionCall rule is trying to define a taxonomy of functions "types", dateTime[Value]Function is an instance of specificFunction that is analogous to case and other built-in functions.

UPDATE: I think I see it, this is probably because you're resing the datetimeValueFunction parse rule to define the left part of date-time functions below.

Yes that was the original motivation, since we can't enforce the arithmetic rules via ArithmeticValue.PhysicalOperator since all the types are just long. I am also making use of it now since datetimeValueFunction needs to create a CurrentTimestampValue with the ConstantObjectValue that corresponds to the evaluation timestamp constant.

hatyo · 2026-10-14T11:02:02Z

    | functionNameKeyword
-    | ASCII | CURDATE | CURRENT_DATE | CURRENT_TIME
-    | CURRENT_TIMESTAMP | CURTIME | DATE_ADD | DATE_SUB
+    | ASCII | DATE_ADD | DATE_SUB


It is good that you removed CURRENT_TIMESTSAMP et al from here, I think this removes a source of ambiguity, (which was probably ok up until now, because we didn't support the removed functions anyway).

hatyo · 2026-10-14T12:34:12Z

+ * A value that evaluates to the evaluation timestamp of the current query, as the number of milliseconds since the
+ * Unix epoch.
+ * <p>
+ * The timestamp is not read from the system clock by this value, instead it is retrieved from the


Yes, I think having this value not reading the current time stamp directly from the machine is definitely the right call.

However, I do believe that we could have it read that particular timestamp constant from the constant box in the bindings instead of having a special binding. This means that the current timestamp will have a (constant) correlation that is provided by the execution context.

This should be addressed now as mentioned in #4645 (comment)

hatyo · 2026-10-14T12:37:47Z

+    @Override
+    public Expression visitIntervalLiteral(final RelationalParser.IntervalLiteralContext ctx) {
+        final var intervalStringLiteralExpression =
+                getDelegate().getPlanGenerationContext().withDisabledLiteralProcessing(() -> visitStringLiteral(ctx.value));


I hope we get to streamline this logic once we introduce a dedicated timestamp and interval types. We can discuss this later.

Just to clarify the logic here a bit we are parsing the interval here to surface a syntax error to the user while generating the logical plan, instead of having something like IntervalValue which does the parsing on evaluation while executing the plan. I don't think the logic here will change much even when we have dedicated types if we are happy with this approach.

hatyo · 2026-10-14T12:39:31Z

+    public Expression visitIntervalLiteral(final RelationalParser.IntervalLiteralContext ctx) {
+        final var intervalStringLiteralExpression =
+                getDelegate().getPlanGenerationContext().withDisabledLiteralProcessing(() -> visitStringLiteral(ctx.value));
+        final var intervalStringLiteralValue =


It looks like the ctx can have either a value or prepared parameter, in either case, I think we should strip it and create a CoV out of it.
It doesn't seem that we're handling the prepared parameter case here.

This was a mistake in the RelationalParser, it shouldn't support prepared parameters here because I went for eagerly parsing the passed interval literals to an actual value while generating the logical plan. We do strip the parsed interval and create a CoV out of that at the end, hence why we disable the literal processing when we parse the string literal.

hatyo · 2026-10-14T12:46:11Z

    private final PlanHashable.PlanHashMode planHashMode;

+    @Nonnull
+    private final Instant evaluationTimestamp;


It looks like we're always setting the evaluation timestamp which would translate to adding 8-bytes to query plan continuations.

That is true, and I tried to change this to make it only added when it is used, but this doesn't work for SQL table functions which might be making use of CURRENT_TIMESTAMP, since at the AstNormalizer level there is no way to know what user-defined table functions are being used and to import the evaluation constants that are referenced in them (I think this is why we add all literals referenced in all temporary functions in the transaction while normalising the query as well).

…stants

…ed queries work

github-actions · 2026-10-23T15:27:33Z

📊 Metrics Diff Analysis Report

Summary

New queries: 7
Dropped queries: 0
Plan changed + metrics changed: 0
Plan unchanged + metrics changed: 0

ℹ️ About this analysis

This automated analysis compares query planner metrics between the base branch and this PR. It categorizes changes into:

New queries: Queries added in this PR
Dropped queries: Queries removed in this PR. These should be reviewed to ensure we are not losing coverage.
Plan changed + metrics changed: The query plan has changed along with planner metrics.
Metrics only changed: Same plan but different metrics

The last category in particular may indicate planner regressions that should be investigated.

New Queries

Count of new queries by file:

yaml-tests/src/test/resources/datetime-value-functions.metrics.yaml: 7

hazefully force-pushed the add-current-time-function branch from f05301a to 9972f31 Compare October 12, 2026 11:41

hazefully mentioned this pull request Oct 13, 2026

Add support for DATETIME and INTERVAL data types #4738

Open

hazefully force-pushed the add-current-time-function branch from 9972f31 to 8079704 Compare October 13, 2026 10:37

hazefully added the enhancement New feature or request label Oct 13, 2026

hazefully force-pushed the add-current-time-function branch 2 times, most recently from 8df6ed4 to 85a8b03 Compare October 13, 2026 13:56

hazefully changed the title ~~Implement interval and CURRENT_TIMESTAMP datetime value function~~ Implement day-time intervals and CURRENT_TIMESTAMP datetime value function Oct 13, 2026

hazefully changed the title ~~Implement day-time intervals and CURRENT_TIMESTAMP datetime value function~~ Implement day-time intervals and current timestamp value function Oct 13, 2026

hazefully force-pushed the add-current-time-function branch 3 times, most recently from 79bf749 to d47daba Compare October 13, 2026 15:09

Implement interval and CURRENT_TIMESTAMP datetime value function

d1b23d5

hazefully force-pushed the add-current-time-function branch from d47daba to d1b23d5 Compare October 13, 2026 15:11

Address Teamscale issues

ae5e11a

hazefully requested a review from hatyo October 13, 2026 16:08

hazefully marked this pull request as ready for review October 13, 2026 16:10

hatyo requested changes Oct 14, 2026

View reviewed changes

hazefully added 12 commits October 14, 2026 14:08

Address additional test gap

0cb0a00

Introduce QueryEvaluationConstants as a wrapper around evaluation con…

54c02bd

…stants

Fix additional newline in BaseVisitor

93b7878

Remove special binding for CurrentTimestampValue

b976346

Ensure that CURRENT_TIMESTAMP() invocations in SQL functions and stor…

6137ddf

…ed queries work

Make intervalLiteral support only string literals

5d38024

Remove unsupported datetime value functions from parser

9862dae

Fix typo in ParseHelpers.java

6a795e1

Ensure NOW also works similar to CURRENT_TIMESTAMP

db9b702

Fix PCurrentTimestampValue in record_query_plan.proto

f17a08a

Merge branch 'main' into add-current-time-function

25e19f9

Fix broken test

aad9aa4

hazefully requested a review from hatyo October 23, 2026 14:13

Fix broken tests and style issues

7e0865f

Conversation

hazefully commented Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The new CURRENT_TIMESTAMP built-in function and value

Interval literals

Supported operations involving interval literals and datetime value functions

Documentation

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot commented Oct 23, 2026

📊 Metrics Diff Analysis Report

Summary

New Queries

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

hazefully commented Sep 21, 2026 •

edited

Loading

The new `CURRENT_TIMESTAMP` built-in function and value