Done

Coding complete for version 2 of the machine. Total lines, including command line, schema, output filtering, output table formatting; about 700 lines.

The following forms work:
@((MySchema:ColName,key1,key2,key3),SomeTripleGraph)

In that case, schema defaulted to the single column search. Schema can expand:

MySchema:(Part1,Part2.Part3),key1,key2...
Were the output picks matches only from column namess Part1,Part2..

This works
MySchema:(SomePattern),_(select* from random_table;)

The underscore gets the attention of the local machine, who always takes it directly to SQL.

The only blocking characters supported is the parentheses, today. It can be context specific, in the case above acting as a quote to collect an sql string.

Output, input, schema all use the sequence frame concept, and any given segment of triples is a set element of its parent, and blocks out a segment of the parent graph. So nesting is natural, and subgraphs update parent graph pointers when done, automatically. The frames have the start and end for sql selects to run through. They have the accumulated match and schema function. They keep a cursor for popping input triples and writing output triples, with the forward looking pointer updated automatically.

Fully nested and schema directed searches are available at the command line, like I type them here. Output can be directed to the screen or to the result table. Outputs are always well formed triple sequences. Row counting in triples start at zero, not one (like SQL).

By nested search I mean:
(key0.(key1,key2,key3),(key4.key5,key6))

But right now it is very inefficient, the select just running the limits and matches filtered out. Need some thought here, like making much closer integration with sql. When the thing is solid, there is lots of room to play with triggers and gfun calls from within sql. Version three will have ten times the efficiency, CPU cycles per match found.