Simple general selects for matches

I talk about the sequence in which a sub query is opened on the match points. The graph structure manages pointer arithmetic and set up a new sub segment, tied to a parent segment with start and end pointers. I use the graph structure throughout, output, setting up sub queries, command line parsing.

The machine starts a sub query by opening graph expressions on output and the two inputs, then when both input tables are at match points, the general select is launched, referencing both table sand referencing the start and possible end point in the respective graph structures.

How complicated is the general select that is installed? As complicated as the developer wants, as long as he gets back to a grammatically correct match point. The machine will run triple from either graph until a triple pops that needs exchange with the other input. Generally that is when the sub query starts.
How complicated, did I ask that?

It can actually be as simple as one wants, the general query can just pop off triples from the other input. That is, the null general select works just fine. That is because this grammar accumulates at match value at match points as starts sub queries. It has to perform the match on the top two nodes, to determine if a query is needed. Hence, if the null general select is desired, the machine will keep on accumulating match value down the sequence. It has no other knowledge of what is going on.

Using the call function, for example, a developer can set the search up to run through 10 or 15 tables, using special selects. At the end of this line of table searching, the operator can emit a READY, and it is back in sync, everything it emitted is in nested order.

Anyway, I have the general select working, but untested for nest sub queries. And pondering the debug cycle for output, I hit upon this simplification, again brought about by a forward pointing grammar. Let 'select next triple' be the default select, and I can test the machine in a completely defaulted situation.

Also, I have enhanced the rowid call back from inside sql. The pop next triple and increment rowid, until the stop row is reached, is now a standard call back. Any installed operator can use it, it guarantees their select range is bound by the graph expression.