Github user fhueske commented on the issue:
https://github.com/apache/flink/pull/4380
Hi @rtudoran,
I had the impression that your main motivation was to fill the syntactic
gaps of SQL on streams and not so much to support certain kinds of use cases.
The semantics of a SQL query are given by the SQL specification and not up
for discussion. If you want to support a certain behavior, we need to see how
this can be expressed in standard-compliant SQL and then think about the
implementation. The semantics of `ORDER BY rowtime ASC FETCH 10 ROWS ONLY` are
given and will return the ten *first* (first because they have the lowest
timestamp) result rows.
However, I think what you are trying to achieve is represented by `ORDER BY
rowtime DESC FETCH 10 ROWS ONLY`. This query returns the ten *last* (last
because they have the highest timestamp) rows of the result. Obviously, we need
retraction to handle this case, because the ten last rows will change over
time. `ORDER BY rowtime DESC OFFSET 10` is also not very useful, because it
holds back the 10 last result rows. However, we could support it to fill the
gap in the syntax and execute the query instead of saying "Sorry, can't do
that".
So the question now is, how do we proceed with this PR? Do we want to add
the `ORDER BY rowtime ASC OFFSET / FETCH` functionality as simple additions to
the existing operators (as I said I think it can be done with very few lines if
we do some refactoring) to fill the syntactic gap or not?
Regardless of whether we add this or not, we should work on the `ORDER BY
rowtime DESC OFFEST / FETCH` case.
What do you think?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
