Kinetica provides support for basic SQL procedures, as an executable batch of SQL statements. A procedure can be executed by two means:
- on-demand - procedure is called directly by a user
- scheduled execution - procedure is configured, upon creation, to execute at a user-specified interval
Even if a procedure is configured for scheduled execution, it can still be executed directly by a user in on-demand fashion.
After the first run, the execution plan for all statements in the procedure will be created and cached to improve performance on future executions.
If there is an error executing any statement in the procedure, the procedure will stop immediately and report the error. If the procedure is invoked via scheduled execution, an alert will be sent to the alert monitor, as there is no interactive session through which the error could be reported to a user. Any database modifications prior to the error will not be rolled back.
If any of the database objects referenced in the procedure are dropped or modified, the procedure will be dropped as well. This does not include any objects created by the procedure that are later referenced by it.
The ability to manage & execute procedures is available through SQL, using the following commands:
For procedure execute permission management, see:
The following statement types are allowed within a SQL procedure:
- INSERT (inserting from data file not supported)
- <CREATE | DROP | SHOW CREATE> SCHEMA
- <CREATE | TRUNCATE | DROP | SHOW CREATE> TABLE
- CREATE TABLE...AS
- <CREATE [MATERIALIZED] | REFRESH | DROP | SHOW CREATE> VIEW
- SHOW PROCEDURE
- SHOW SECURITY [FOR <USER | ROLE>]
- SHOW RESOURCE GROUP
Any unqualified table/view references made within the procedure will be assumed to exist in the procedure creator's default schema at the time of creation. Those references will be set upon creation and never re-evaluated afterwards, regardless of the execution type of the procedure, who executes it, or what EXECUTE AS option is specified.
|<schema name>||Name of the schema in which this procedure will be created|
|<procedure name>||Name to give to the created procedure; must adhere to the supported naming criteria for tables, and cannot be named the same as any existing table or view|
|<sql statements>||Semicolon-separated list of supported SQL statements. If the final statement in the procedure is an output-generating statement (SQL query, SHOW command, etc.), the output of that statement alone will be returned to the user; all other statements that generate output will be ignored.|
|OR REPLACE||Drop any existing procedure with the same name before creating this one|
|LANGUAGE||Optional language specification for the procedure. Only SQL is supported at this time.|
|<number>||Length of time, in the given number of units, between scheduled executions of the procedure. Fractional values are accepted.|
Optional indicator that a comma-delimited list of option/value assignments will follow. The following options are available:
For example, to create a sqlp procedure:
To create a sqlp_weekly procedure that executes once per week:
The following facet of a view can be altered:
Set Execution User
A stored procedure can have its execution user modified.
For example, to set the execution user of the sqlp_ea procedure to spuser:
SQL procedures can be executed on-demand.
If the final statement in the procedure is an output-generating statement (SQL query, SHOW command, etc.), the output of that statement alone will be returned to the user; all other statements that generate output will be ignored.
If there is an error executing any statement in the procedure, the procedure will stop immediately and report the error. Any database modifications prior to the error will not be rolled back.
For example, to execute the sqlp procedure:
When removing a SQL procedure from the database, there are two options available, which control how the removal takes place. Normally, an error will be reported if the table to drop doesn't exist; if IF EXISTS is specified, no error will be reported.
For example, to drop the sqlp procedure:
The content of a SQL procedure can be displayed.
For example, to show the contents of the sqlp_weekly procedure:
Permissions for managing procedures follow those for creating tables; e.g., if a user has the ability to create a table in a given schema, that user will also be able to create & drop procedures there.
Executing a procedure requires either the implicit execute permission that is granted to the creator of a procedure, or explicit execute permission, which can be granted to or revoked from any user or role, irrespective of whether the target user or role has the appropriate access to the database objects referenced within the SQL procedure.
When procedures are executed on-demand, they are run, by default, with invoker rights (caller permissions); while those run automatically by scheduled execution are executed with definer rights (creator permissions). These defaults can be overridden by creating the stored procedure with the EXECUTE AS option, which allows a user to be designated for permissions-checking when running the procedure. The EXECUTE AS user is automatically given EXECUTE permission on the corresponding SQL procedure.
For scheduled execution runs, if the EXECUTE AS user loses EXECUTE permission on the procedure or doesn't have permissions to run the commands within the procedure, the execution will fail accordingly. If the user doesn't exist, the procedure will be executed with definer rights; and if the creator no longer exists, it will be executed as the system adminstration user.
For on-demand runs, if the EXECUTE AS user doesn't have permissions to run the commands within the procedure, the execution will fail accordingly. If the user doesn't exist, the procedure will be executed with invoker rights.
Execute permission on a procedure also allows the grantee to see the contents of the procedure.