The general select is driven, at the top, by the schema, including the default schema. Nothing can happen until we get a schema go ahead. Schema patterns are conformal g graphs enclosed by the schema operator. If we inclde the default null schema among accepted forms, then the schema match is just like another, that is, just a convolution among friendly g things.
So, a match point (SQLITE_DONE) first triggers the schema, which then takes over the sequencing of tables for the next general select. Schema first matches the two schema, popping the one or the other as long as it gets a pass. But each trigger of the schema, triggers a select, until schema end. The schema handler may sub select the general select operator, based upon schema state, and it controls select bounds for value data with access to the pointers. The chosen general select then generates value data triples (SQUARE or otherwise), which is handled by the handler selected in the schema handler, if you can handle that. The point is, schema is the primary control filter, then it launches value data selection, as needed. It pops its own possible schema stacks (0,1, or 2), based upon wild key modifiers. The thing should nest properly, I think.
Do we have algebra on that?
@((Sch1:(pattern1,values1,,,)),(Sch2:(pattern2,values2,,,)) ->
@(_:@(pattern1,pattern2),@(values1,,),(values2..))
Dunno, above my pay grade. But the machine will compute it, whether it causes data base geeks to say, Yea, that makes sense, well, dunno.
No comments:
Post a Comment