[kwlug-disc] SQLPage can be more SQL-y

[Mikalai Birukou]

{as a follow up to SQLPage presentation}

SQL is a structured language. Both parts are important: structured and 
language.

If you ever had to construct programmatically queries, you'd think that 
building an SQL query was designed for this process. May be someone can 
point at architecture discussions and history.

Now comes a ingenuously simple idea: instead of erasing structure that 
comes from query results, feed it directly into structure of 
automatically generated page, be it html, json, or future may want a 
gRPC, etc.
SQLPage's magic and wisdom is in cutting it straight. Sailing with the 
wind, not against it.

On the language side, though, many of us where confused. And rightfully 
so. How does it look to an English speaking person: select, select, 
select. Besides, being a marker that has some meaning for computer, 
"select" implies common select/take action. And subconscious mind gets 
confused: why choisir has a meaning of display?

SQLPage adds a display of data. That's it.
All respectable SQL databases have their own additional words added to 
common SQL, like "SHOW" in MySQL, and so on.

Imagine file for json endpoint is
RENDER JSON FROM ...query...

Or, how about for html
RENDER HTML _html_component_tag_ WITH ...select_query...
RENDER HTML _html_form_tag_ WITH ...select_query... DO ....

These kinds of extensions will make SQLPage more SQL-y, like Postgres' DO.

Side note 1: Of course, one can't ask for this at the very early stage 
of a project. I wonder whether it is easy or non-trivial to add these 
extensions to parser that is used in SQLPage (disclaimer, haven't 
checked code in details).

Side note 2: If someone insist that ultimately world is made of 
select's, we should remind them, that it is made of lists, and this 
direction of design has also traversed.