For quite a while we have had partial support for MATCH_RECOGNIZE. We support 
it in the parser and validator, but there is no runtime implementation. It’s a 
shame, because MATCH_RECOGNIZE is an incredibly powerful SQL feature for both 
traditional SQL (it’s in Oracle 12c) and for continuous query (aka complex 
event processing - CEP).

I figure it’s time to change that. My plan is to implement it incrementally, 
getting simple queries working to start with, then allow people to add more 
complex queries.

In a dev branch [1], I’ve added a method Enumerables.match[2]. The idea is that 
if you supply an Enumerable of input data, a finite state machine to figure out 
when a sequence of rows makes a match (represented by a transition function: 
(state, row) -> state), and a function to convert a matched set of rows to a 
set of output rows. The match method is fairly straightforward, and I almost 
have it finished.

The complexity is in generating the finite state machine, emitter function, and 
so forth.

Can someone help me with this task? If your idea of fun is implementing 
database algorithms, this is about as much fun as it gets. You learned about 
finite state machines in college - this is your chance to actually write one!

This might be a good joint project with the Flink community. I know Flink are 
thinking of implementing CEP, and the algorithm we write here could be shared 
with Flink (for use via Flink SQL or via the Flink API).

Julian

[1] https://github.com/julianhyde/calcite/commits/1935-match-recognize 
<https://github.com/julianhyde/calcite/commits/1935-match-recognize>

[2] 
https://github.com/julianhyde/calcite/commit/4dfaf1bbee718aa6694a8ce67d829c32d04c7e87#diff-8a97a64204db631471c563df7551f408R73
 
<https://github.com/julianhyde/calcite/commit/4dfaf1bbee718aa6694a8ce67d829c32d04c7e87#diff-8a97a64204db631471c563df7551f408R73>

Reply via email to