Add stored procedures about catena

[pixelspark]

Could be implemented by granting execution rights for an SQL statement that (in canonical form) hashes to a certain value. The SQL would contain placeholders for variables which would be filled in after validation. This appears to be like https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki.

[pixelspark]

Define a template:

INSERT INTO x (y,z) VALUES(#q, 1);

The hash of this template is stored in a grants table.

Use a template:

INSERT INTO x (y,z) VALUES (#q='some value', 1);

When processing a transaction with this query in it, the engine removes all parameter values and arrives at the 'template query'. This is hashed in order to search for execution rights. When these rights are present, the original query is stripped off its parameter indicators ('#x') and executed normally.

Some thoughts:

• Any (constant) SQL value should be usable as value (e.g. #param=(1+1) should be legal)
• The same parameter may appear multiple times in a query. In this case the values should be equal
• Unnamed parameters may be used (#='xx'), these cannot be re-used obviously in the same query.
• The definer of the query must have the rights to execute the query 'on behalf' of the invoker. A stored procedure really is a delegated query executed with rights of the delegator.
• We may want to add a variable indicating the definer of the procedure
• There needs to be a way to run multiple queries atomically in the same procedure. Procedures should execute in a transaction.
• Should it also be possible to store not the hash but the template itself? This would provide a bit more information about procedures available, otherwise needs to be done out of band.

We should also add support for some sort of IF-statement, in order to be able to validate inputs, e.g.:

CASE 
WHEN #amount > 0 THEN UPDATE balance SET balance = balance - #amount 
WHEN #amount = 0 THEN IGNORE
ELSE FAIL 
END

Use cases:

• Expiring: CASE WHEN $timestamp > someTime THEN FAIL ELSE [query] END
• Customizing rights: CASE WHEN $invoker=x AND #amount<y THEN [query] ELSE FAIL END

[pixelspark]

So there is still a use case for stored procedures, and that is to componentize (sub)statements and also publicly show them in the database. I propose the following:

• Have a special (optional) procedures table with structure (name TEXT PRIMARY KEY, statement TEXT) store special statements by name.
• Add a permission kind call with subject referring to one of the stored procedures in that table.
• Add a CALL SQL statement that allows calling a stored procedure (if you have permissions). We do need a way to pass parameters (something like CALL transfer(to:x, from:y, amount: z).

There also needs to be a recursion limit (e.g. the stack may contain at most x CALL statements).