SQL Procedures

Kinetica provides support for basic SQL procedures, as an executable batch of SQL statements. A SQL procedure can be executed by two means:

  • on-demand - called directly by a user
  • scheduled execution - configured, upon creation, to execute at a user-specified interval

Note

Even if a SQL 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 SQL procedure will be created and cached to improve performance on future executions.

If there is an error executing any statement, the SQL procedure will stop immediately and report the error. If it 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.

Note

If any of the database objects referenced in the SQL procedure are dropped or modified, the SQL procedure will be dropped as well. This does not include any objects created by the SQL procedure that are later referenced by it.

The ability to manage & execute SQL procedures is available through SQL, using the following commands:

For execute permission management, see:


Supported Statements

The following statement types are allowed within a SQL procedure:

  • SELECT
  • INSERT (inserting from data file not supported)
  • UPDATE
  • DELETE
  • <CREATE | DROP | SHOW CREATE> SCHEMA
  • <CREATE | TRUNCATE | DROP | SHOW CREATE> TABLE
  • CREATE TABLE...AS
  • <CREATE [MATERIALIZED] | REFRESH | DROP | SHOW CREATE> VIEW
  • DESCRIBE
  • SHOW PROCEDURE
  • SHOW SECURITY [FOR <USER | ROLE>]
  • SHOW RESOURCE GROUP

Note

Any unqualified table/view references made within the SQL procedure will be assumed to exist in the 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 SQL procedure, who executes it, or what EXECUTE AS option is specified.

CREATE PROCEDURE

Creates a new SQL procedure.

CREATE PROCEDURE Syntax
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
CREATE [OR REPLACE] PROCEDURE [<schema name>.]<procedure name> [()]
[LANGUAGE SQL]
BEGIN
    <sql statements>
END
[
    EXECUTE FOR EVERY <number> <SECOND[S] | MINUTE[S] | HOUR[S] | DAY[S]>
    [STARTING AT '<YYYY-MM-DD [HH:MM[:SS]]>']
]
[WITH OPTIONS (<stored procedure property name> = '<stored procedure property value>'[,...])]

When any of the source tables referenced by a SQL procedure is altered or dropped, the SQL procedure will also be dropped.

Parameters Description
<schema name> Name of the schema in which this SQL procedure will be created
<procedure name> Name to give to the created SQL 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 SQL 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 SQL procedure with the same name before creating this one
LANGUAGE Optional language specification. Only SQL is supported at this time.
<number> Length of time, in the given number of units, between scheduled executions of the SQL procedure. Fractional values are accepted.
WITH OPTIONS

Optional indicator that a comma-delimited list of option/value assignments will follow. The following options are available:

Option Description
EXECUTE AS

Executes the SQL procedure as the given user with that user's privileges.

Note

If this user doesn't exist at the time of execution, the SQL procedure will be executed as the creating user, and and, failing that, the system administration user.

For example, to create a sqlp SQL procedure:

CREATE PROCEDURE Example
1
2
3
4
5
6
7
8
9
CREATE PROCEDURE example.sqlp
BEGIN
  CREATE OR REPLACE TABLE example.sqlp_table_tmp AS
  SELECT *
  FROM example.sqlp_table_ref;

  SELECT *
  FROM example.sqlp_table_tmp;
END

To create a sqlp_weekly SQL procedure that executes once per week:

CREATE PROCEDURE (Scheduled) Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
CREATE PROCEDURE example.sqlp_weekly
BEGIN
  CREATE OR REPLACE TABLE example.sqlp_table_tmp AS
  SELECT *
  FROM example.sqlp_table_ref;

  SELECT *
  FROM example.sqlp_table_tmp;
END 
EXECUTE FOR EVERY 7 DAYS
STARTING AT '2019-01-01 00:00:00'

ALTER PROCEDURE

Alters the configuration of an existing SQL procedure.

The following facet of a SQL procedure can be altered:

Set Execution User

A SQL procedure can have its execution user modified.

Set Procedure Execution User Syntax
1
2
ALTER PROCEDURE [<schema name>.]<procedure name>
SET EXECUTE AS '<user name>'

For example, to set the execution user of the sqlp_ea SQL procedure to spuser:

ALTER PROCEDURE SET EXECUTE AS Example
1
2
ALTER PROCEDURE example.sqlp_ea
SET EXECUTE AS 'spuser'

EXECUTE PROCEDURE

SQL procedures can be executed on-demand.

EXECUTE PROCEDURE Syntax
1
EXEC[UTE] [PROCEDURE] [<schema name>.]<procedure name> [()]

If the final statement in the SQL 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, the SQL 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 SQL procedure:

EXECUTE PROCEDURE Example
1
EXECUTE PROCEDURE example.sqlp

DROP PROCEDURE

Removes an existing SQL procedure.

DROP PROCEDURE Syntax
1
DROP PROCEDURE [IF EXISTS] [<schema name>.]<procedure name>
Parameters Description
IF EXISTS Optional error-suppression clause; if specified, no error will be returned if the given procedure does not exist
<schema name> Name of the schema containing the procedure to remove
<procedure name> Name of the procedure to remove

For example, to drop the sqlp SQL procedure:

DROP PROCEDURE Example
1
DROP PROCEDURE example.sqlp

SHOW PROCEDURE

Shows the content of an existing SQL procedure.

SHOW PROCEDURE Syntax
1
SHOW PROCEDURE [<schema name>.]<procedure name>
Parameters Description
<schema name> Name of the schema containing the procedure to show
<procedure name> Name of the procedure whose content will be output

For example, to show the contents of the sqlp_weekly procedure:

SHOW PROCEDURE Example
1
SHOW PROCEDURE example.sqlp_weekly

Security

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.