Collecting SQL columns with the schema operator

We want to view large square tables in graph syntax, how to we interpret a  table with many rows that can selected.  In typeface explosion, it looks like this query.

@((col1:col3:col8:),SomeTableStore)

Where the col1 name may be either the actual name or the standard alias, who cares. Some table may have 20 columns, who knows. So table store are comma separated rows of descending columns?  Rows are generally treated as a set, but here we are treating columns as a set. I think columns in a row are a bit heavier than comma separated byt a bit lighter than and descents.

How can we make an embedded sqlite3 generate triples from variably selected columns?
A compound sql selector run as often as the schema demands. Use a single statement:
insert into result select ?,link,pointer 
from squaretable
where other match and row conditons meet;


The question mark here is used in sqlite3 to bind literals to variables before running the statement, and is replacrd by squaretable.column.  So run that statement as often as the graph matcher clicks through the schema operators.  That is a combination of  some embedded code working in cooperation with an embedded sql.  The embedded code knows about both sql columns and graph schema links.  Later in a future version, make the operation even more embedded. For example, just install a call back on column schema, collect the whole row then apply the schema o it column by column in the engine. I will likely do this, refer to the grammar page in the engine section.

The grammar tells engine developers that the sequence: col1:col2:col3 can be stacked, and run as a subgraph, clicking off triple from the elect column.    That sequence is a simple repeated three node descent.  The schema operators appearing as a sequence of triple from the table other, for example.  The G machine need simple step by the node until it gets a descent termination, then overload the schema operator, and re run the same three nodes over repeatedly on each row sqlite_row.

Storing text blobs in each column is a great idea, no need to be triple compatible, run as many columns as you like.

What about: col1:*col4:col8   Grab col1 to cl4 and col8, right, if the wildcard means match and select. But is doesn't mean collect all schema. Bu wait, you say, shouldn't that be:  col1:*:col4:col8  Probably, making sure we select the data, not the schema itself. Yes, I think wikld cards are stationary wild keywords, with a possible repeat indefinitely link overload.

How about schema as a very lighweight operator, like convolution. It appear in his form:
:(A,B.(C,D),G)  where the schema refers to the whole patter i the expression.  That way we get bth structure and name in schemas.  So picking off rows of a table: :(col1,col2,col6.col9.col10,col20)


The graph machine will need to know about wild card, repeat indefinitely, and not operators.  They are like overloads.   But we want the machine to know about these very mechanically.  But a general syntax interpreter for graphs is only a few lines of code. So the machine marks the schema start operator and marks schema end pattern. It clicks through the patter emitting a insert selects to sql. The schema pattern, in default, indicates the nesting on output result. Thus a square table can be picked through by column assembling an arbitrary nesting pattern.