Thank you Julian for mentioning the anti-join. With its help, I managed to
solve our particular case similarly as follows:
```
SELECT e.*
FROM events e
LEFT JOIN patterns p
ON e.record_id = p.begin_record_id
WHERE e.pattern_val = 'BEGIN' AND p.begin_record_id is null
```
However, I'm thinking
Is there a better way?
I'm am idealist with regard to streaming SQL semantics, and I'm going
to make the 'slippery slope' argument that if we add a TIMEOUT
parameter to MATCH_RECOGNIZE, won't we also need to add it to GROUP BY
and JOIN? (Because those are also "blocking" operators.)
Maybe JOIN
Hi Jark,
Thank you for your e-mail. I agree, let's engage all interested parties in this
discussion - I'm writing this e-mail to both Flink and Calcite dev mailing
lists.
I'll repeat myself to present the proposal to the Calcite community.
I would like to propose an enrichment of existing
Hi Kosma,
Thanks for the proposal. I like it and we also have supported similar
syntax in our company.
The problem is that Flink SQL leverages Calcite as the query parser, so if
we want to support this syntax, we may have to push this syntax back to the
Calcite community.
Besides, the SQL
Hello,
I would like to propose an enrichment of existing Flink SQL MATCH_RECOGNIZE
syntax to cover for the case of the absence of an event. Such an enrichment
would help our company solve a business case containing timed-out patterns
handling. An example of usage of such a clause from Flink
