Implement now/current_date/current_time/current_timestamp

[neverchanje]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I think now is one of the most important functions around time. I'm a little surprised that we don't support that.

https://www.postgresql.org/docs/current/functions-datetime.html

• now ( ) → timestamp with time zone
  Current date and time (start of current transaction); see Section 9.9.5
  now() → 2019-12-23 14:39:53.662522-05

• current_timestamp → timestamp with time zone
  Current date and time (start of current transaction); see Section 9.9.5
  current_timestamp → 2019-12-23 14:39:53.662522-05

PostgreSQL support several different times:

• time of parsing (not suitable for table default, prepared statement, view): timestamptz 'now'
• time of transaction start: current_xxx, localxxx, transaction_timestamp(), now()
• time of statement start: statement_timestamp()
• time of function eval (f() = f() may be false depending on resolution): clock_timestamp(), timeofday()

[skyzh]

This function is not deterministic, and cannot be implemented in stream engine.

[neverchanje]

ahh, I see, but in batch it's can be supported right?

[xiangjinwu]

They are not pure functions. Maybe we should rewrite them as literals in frontend rather than pass them to backend expr.eval().

[fuyufjh]

For streaming engine, an option is to implement now() to extract the current physical time from epoch.

An alternative is to add a hidden time column for every source as the ingestion time of event.

[liurenjie1024]

For streaming engine, an option is to implement now() to extract the current physical time from epoch.

An alternative is to add a hidden time column for every source as the ingestion time of event.

If we want to change its underlying meaning, we'd better use a new function name and tells user now() not supported in mv.

[skyzh]

rw_timestamp_now() !

[fuyufjh]

If we want to change its underlying meaning, we'd better use a new function name and tells user now() not supported in mv.

We may also use this semantic for now() of batch i.e. extracting current time from epoch instead of call system's clock. Users won't be aware of this difference, I think.

However, users get a benefit that he can now just copy the batch query to create materialized view with it.

[liurenjie1024]

If we want to change its underlying meaning, we'd better use a new function name and tells user now() not supported in mv.

We may also use this semantic for now() of batch i.e. extracting current time from epoch instead of call system's clock. Users won't be aware of this difference, I think.

However, users get a benefit that he can now just copy the batch query to create materialized view with it.

What if epoch is set to a large value(for example, several minutes)?

[fuyufjh]

What if epoch is set to a large value(for example, several minutes)?

That's a problem 🤔 Unless we decouple epoch from checkpoint

[twocode]

Any progress with this? 🤔

[fuyufjh]

If you are seeking a continuously changing timestamp in the stream, please refer to #7209, which has both better-defined semantics and more straightforward implementation.

[fuyufjh]

My idea is to forbid now() in streaming queries except temporal filters i.e. in the where clause, so let's close this issue now.