You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common requirement in data processing is to only process data with a given range of the current time. Therefore support for a function such as SYSDATE (or whatever we call it) would be useful.
For example:
SELECT * FROM SOURCE_STREAM WHERE END_DATE < SYSDATE
To make this properly useful we'd also need date arithmetic so that you could offset the current time.
Whilst this fixed-time processing may not be 'pure' in the true streaming sense of the world (for example, how do you consider late arriving data in this concept, do you compare it to current time now etc), it is useful for many 'normal' applications in which people are shifting from doing work in the DB to doing it in KSQL.
The text was updated successfully, but these errors were encountered:
this was merged into master after 5.3 was cut I think, so will it be in the next 5.3.x release?
Yes, that's correct. The new UNIX_TIMESTAMP and UNIX_DATE functions did not make it into 5.3. They will be included in the next release after 5.3 (i.e., 5.4).
A common requirement in data processing is to only process data with a given range of the current time. Therefore support for a function such as SYSDATE (or whatever we call it) would be useful.
For example:
To make this properly useful we'd also need date arithmetic so that you could offset the current time.
Whilst this fixed-time processing may not be 'pure' in the true streaming sense of the world (for example, how do you consider late arriving data in this concept, do you compare it to current time now etc), it is useful for many 'normal' applications in which people are shifting from doing work in the DB to doing it in KSQL.
The text was updated successfully, but these errors were encountered: