Writing stored procedures in Snowflake Scripting¶
This topic provides an introduction to writing a stored procedure in SQL by using Snowflake Scripting. For more information about Snowflake Scripting, see the Snowflake Scripting Developer Guide.
Introduction¶
To write a stored procedure that uses Snowflake Scripting:
Use the CREATE PROCEDURE or WITH … CALL … command with LANGUAGE SQL.
In the body of the stored procedure (the AS clause), you use a Snowflake Scripting block.
Note
If you are creating a Snowflake Scripting procedure in SnowSQL or Snowsight, you must use string literal delimiters (
'or$$) around the body of the stored procedure.For details, see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector.
Snowflake limits the maximum size of the source code in the body of a Snowflake Scripting stored procedure. Snowflake recommends limiting the size to 100 KB. (The code is stored in a compressed form, and the exact limit depends on the compressibility of the code.)
You can capture log and trace data as your handler code executes. For more information, see Logging, tracing, and metrics.
Note
The same rules around caller’s rights vs. owner’s rights apply to these stored procedures.
The same considerations and guidelines in Working with stored procedures apply to Snowflake Scripting stored procedures.
The following is an example of a simple stored procedure that returns the value of the argument that is passed in:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following is an example of calling the stored procedure:
The following is an example of creating and calling an anonymous stored procedure by using the WITH … CALL … command:
Note that in an anonymous stored procedure, you must use string literal delimiters ('
or $$) around the body of the procedure.
Using arguments passed to a stored procedure¶
If you pass in any arguments to your stored procedure, you can refer to those arguments by name in any Snowflake Scripting expression. Snowflake Scripting stored procedures support input (IN) and output (OUT) arguments.
When you specify an output argument in the definition of a Snowflake Scripting stored procedure, the stored procedure can return the current value of the output argument to a calling program, such as an anonymous block or a different stored procedure. The stored procedure takes an initial value for the output argument, saves the value to a variable in the procedure body, and optionally performs operations to change the value of the variable, before returning the updated value to the calling program.
For example, a salesperson’s user identifier and a sales quarter can be passed to a stored procedure named
emp_quarter_calling_sp_demo. This stored procedure calls a different stored procedure named
sales_total_out_sp_demo. The sales_total_out_sp_demo stored procedure has an output argument that
performs operations to return the salesperson’s total sales for the quarter to the calling stored procedure
emp_quarter_calling_sp_demo. For an example of this scenario, see
Using an output argument to return the total sales for an employee in a quarter.
When there is a mismatch between the data type of the value being passed in and the data type of the output argument, supported coercions are performed automatically. For an example, see Using an output argument with a different data type than the input value from a calling procedure. For information about which coercions Snowflake can perform automatically, see Data types that can be cast.
The GET_DDL function and the SHOW PROCEDURES command show the
type (either IN or OUT) of a stored procedure’s arguments in output. Other commands and views that show
metadata about stored procedures don’t show the type of the arguments, such as the DESCRIBE PROCEDURE
command, the Information Schema PROCEDURES view, and the Account Usage
PROCEDURES view.
A stored procedure can’t be overloaded by specifying different argument types in the signature. For example, assume a stored procedure has this signature:
The following CREATE PROCEDURE command fails with an error stating that the procedure already exists, because it tries to create a new stored procedure that differs from the previous example only in the argument type:
Syntax¶
Use the following syntax to specify an argument in a Snowflake Scripting stored procedure definition:
Where:
arg_nameThe name of the argument. The name must follow the naming rules for Object identifiers.
{ IN | INPUT | OUT | OUTPUT }Optional keyword that specifies whether the argument is an input argument or an output argument.
INorINPUT- The argument is initialized with the supplied value, and this value is assigned to a stored procedure variable. The variable can be modified in the stored procedure body, but its final value can’t be passed to a calling program.INandINPUTare synonymous.OUTorOUTPUT- The argument is initialized with the supplied value, and this value is assigned to a stored procedure variable. The variable can be modified in the stored procedure body, and its final value can be passed to a calling program. In a stored procedure body, output arguments can only be assigned values by using variables.Output arguments can also be passed uninitialized variables. When the associated variable is unassigned, the output argument returns NULL.
OUTandOUTPUTare synonymous.
Default:
INarg_data_type
Limitations¶
Output arguments must be specified in a stored procedure’s definition.
Output arguments can’t be specified as optional arguments. That is, output arguments can’t be specified using the DEFAULT keyword.
In the body of a stored procedure, variables must be used to assign values to output arguments.
The same variable can’t be used for multiple output arguments.
Session variables can’t be passed to output arguments.
User-defined functions (UDFs) don’t support output arguments.
Stored procedures written in languages other than SQL don’t support output arguments.
Output arguments can’t be used in asynchronous child jobs.
Stored procedures are limited to 500 arguments, including both input and output arguments.
Examples¶
Simple example of using arguments passed to a stored procedure
Using an argument when building a string for a SQL statement
Using output arguments to return several values for multiple calls to a stored procedure
Using an output argument with a different data type than the input value from a calling procedure
Using an output argument to return the total sales for an employee in a quarter
Simple example of using arguments passed to a stored procedure¶
The following stored procedure uses the values of the arguments in IF and RETURN statements.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following is an example of calling the stored procedure:
Using an argument in a SQL statement (binding)¶
As is the case with Snowflake Scripting variables, if you need to use an argument in a SQL statement, put a colon (:) in front
of the argument name. For more information, see Using a variable in a SQL statement (binding).
The following sections contain examples that use bind variables in stored procedures:
Example of using a bind variable to set the value of a property
Example that uses bind variables to set parameters in a command
Example that uses a bind variable in a WHERE clause¶
The following stored procedure uses the id argument in the WHERE clause of a SELECT statement. In the WHERE
clause, the argument is specified as :id.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following is an example of calling the stored procedure:
In addition, the TO_QUERY function provides a simple syntax for accepting a SQL string directly in the FROM clause of a SELECT statement. For a comparison of the TO_QUERY function with dynamic SQL, see Constructing SQL at runtime.
Example of using a bind variable to set the value of a property¶
The following stored procedure uses the comment argument to add a comment for a table in a
CREATE TABLE statement. In the statement, the argument is specified as :comment.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following is an example of calling the stored procedure:
View the comment for the table by querying the TABLES view in the INFORMATION_SCHEMA:
You can also view the comment by running a SHOW TABLES command.
Example that uses bind variables to set parameters in a command¶
Assume you have a stage named st with CSV files:
You want to load the data in the CSV files into a table named test_bind_stage_and_load:
The following stored procedure uses the FROM, ON_ERROR, and VALIDATION_MODE parameters in
a COPY INTO <table> statement. In the statement, the parameter values are specified as
:my_stage_name, :on_error, and :valid_mode, respectively.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following is an example of calling the stored procedure:
Examples that use a bind variable for an array¶
You can expand a bind variable that represents an array into a list of individual values
by using the spread operator (**). For more information and examples, see Expansion operators.
Using an argument as an object identifier¶
If you need to use an argument to refer to an object (for example, a table name in the FROM clause of a SELECT statement), use the IDENTIFIER keyword to indicate that the argument represents an object identifier. For example:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following is an example of calling the stored procedure:
The following example executes a CREATE TABLE … AS SELECT (CTAS) statement in a stored procedure based on the table names provided in arguments.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Before calling the procedure, create a simple table and insert data:
Call the stored procedure to create a new table that is based on this table:
Using an argument when building a string for a SQL statement¶
Note that if you are building a SQL statement as a string to be passed to EXECUTE IMMEDIATE (see Assigning a query to a declared RESULTSET), do not prefix the argument with a colon. For example:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Using an output argument to return a single value¶
The following example creates the stored procedure simple_out_sp_demo with the output argument xout in
its definition. The stored procedure sets the value of xout to 2.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following anonymous block sets the value of the x variable to 1. Then, it calls the simple_out_sp_demo
stored procedure and specifies the variable as the argument.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The output shows that the simple_out_sp_demo stored procedure performed an operation to set the value of the
output argument to 2 and then returned this value to the anonymous block.
The following anonymous block calls simple_out_sp_demo stored procedure and returns an error, because it tries to
assign a value to the output argument using an expression instead of a variable.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Using output arguments to return several values for multiple calls to a stored procedure¶
The following example demonstrates the following behavior related to stored procedures and input and output arguments:
A stored procedure can have several input and output arguments in its definition.
A program can call a stored procedure with output arguments multiple times, and the values of the output arguments are preserved after each call.
Input arguments don’t return values to the calling program.
Create the stored procedure multiple_out_sp_demo with multiple input and output arguments in its
definition. The stored procedure performs the same operations on the equivalent input and output arguments.
For example, the stored procedure adds 1 to the p1_in input argument and to the p1_out output
argument.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following anonymous block assigns values to the variables that correspond to the arguments of the
multiple_out_sp_demo stored procedure and then calls the stored procedure multiple times. The first
call uses the variable values specified in the anonymous block, but each subsequent call uses the values
returned by the output arguments in the multiple_out_sp_demo stored procedure.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Using an output argument with a different data type than the input value from a calling procedure¶
For some use cases, there might be a mismatch between the data type of the value being passed in to a stored procedure and the data type of the procedure’s output argument. In these cases, supported coercions are performed automatically.
Note
Although coercion is supported in some cases, it isn’t recommended.
This example demonstrates automatic conversion of a FLOAT value that is passed to an output argument with a NUMBER data type. The FLOAT value is automatically converted to a NUMBER value and then passed back to the calling anonymous block.
Create the sp_out_coercion stored procedure, which takes an output argument of type NUMBER:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Execute an anonymous block that passes a FLOAT value to the sp_out_coercion stored procedure:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The output shows both the returned value and the data type of the returned value, by calling the SYSTEM$TYPEOF function. Note that the value is coerced from a NUMBER value back to a FLOAT value after it is returned from the stored procedure:
Using an output argument to return the total sales for an employee in a quarter¶
This example uses the following quarterly_sales table:
Create the stored procedure sales_total_out_sp_demo that takes two input arguments for the
employee identifier and quarter, and one output argument to calculate the sales total for the
given employee and quarter.
Create the stored procedure emp_quarter_calling_sp_demo that calls the sales_total_out_sp_demo
stored procedure. This stored procedure also takes two input arguments for the employee identifier and quarter.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Call the emp_quarter_calling_sp_demo with the arguments 2 (for the employee identifier) and
'2023_Q4' (for the quarter).
Returning tabular data¶
If you need to return tabular data (for example, data from a RESULTSET) from your stored procedure, specify RETURNS TABLE(…) in your CREATE PROCEDURE statement.
If you know the Snowflake data types of the columns in the returned table, specify the column names and types in the RETURNS TABLE().
Otherwise (for example, if you are determining the column types during run time), you can omit the column names and types:
Note
Currently, in the RETURNS TABLE(...) clause, you can’t specify GEOGRAPHY as a column type. This
applies whether you are creating a stored or anonymous procedure.
If you attempt to specify GEOGRAPHY as a column type, calling the stored procedure results in the error:
To work around this issue, you can omit the column arguments and types in RETURNS TABLE().
If you need to return the data in a RESULTSET, use TABLE() in your RETURN statement.
For example:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following is an example of calling the stored procedure:
Calling a stored procedure from another stored procedure¶
In a stored procedure, if you need to call another stored procedure, use one of the following approaches:
Calling a stored procedure without using the returned value¶
Use a CALL statement to call the stored procedure (as you normally would).
If you need to pass in any variables or arguments as input arguments in the CALL statement, remember to use a colon (:) in
front of the variable name. (See Using a variable in a SQL statement (binding).)
The following is an example of a stored procedure that calls another stored procedure but does not depend on the return value.
First, create a table for use in the example:
Then, create the stored procedure that you will call from another stored procedure:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Next, create a second stored procedure that calls the first stored procedure:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Finally, call the second stored procedure:
Using the value returned from a stored procedure call¶
If you are calling a stored procedure that returns a scalar value, and you need to access that value, use the
INTO :snowflake_scripting_variable clause in the CALL statement to capture the value in a
Snowflake Scripting variable.
The following example calls the get_row_count stored procedure that was defined in
Using an argument as an object identifier.
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
The following is an example of calling the stored procedure:
If the stored procedure returns a table, you can capture the return value by setting a RESULTSET to a string containing the CALL statement. (See Assigning a query to a declared RESULTSET.)
To retrieve the return value from the call, you can use a CURSOR for the RESULTSET. For example:
Passing output argument values from a stored procedure to a calling stored procedure¶
When an output argument is specified in the definition of a Snowflake Scripting stored procedure, the stored procedure can return the current value of the output argument to a calling stored procedure. The stored procedure takes an initial value for the output argument, saves the value to a variable in the procedure body, and optionally performs operations to change the value of the variable. The stored procedure then returns the updated value to the calling stored procedure.
For an example, see Using an output argument to return the total sales for an employee in a quarter.
Using nested stored procedures¶
A nested stored procedure is a stored procedure that’s defined within the scope of an anonymous block or a block in another stored procedure (the parent stored procedure).
You declare a nested stored procedure in the DECLARE section of a block, which can be part of a CREATE PROCEDURE statement. The following example shows a nested stored procedure declaration:
For information about the declaration syntax of a nested stored procedure, see Nested stored procedure declaration syntax.
A nested stored procedure only exists within the scope of its block. It can be called from any section of its block (DECLARE, BEGIN … END, and EXCEPTION). A single block can contain multiple nested stored procedures, and one nested stored procedure can call another nested stored procedure in the same block. A nested procedure can’t be called or accessed from outside of its block.
A nested stored procedure operates in the same security context as the block that defines it. When a nested stored procedure is defined in a parent stored procedure, it automatically runs with the same privileges as the parent stored procedure.
Note
Both a nested stored procedure declaration and the CALL WITH command create a temporary stored procedure with limited scope. They differ in the following ways:
A CALL WITH statement can appear anywhere that a SQL statement can, including within a stored procedure, but a nested stored procedure declaration must be in a Snowflake Scripting block.
A CALL WITH stored procedure only exists in the scope of its statement, but a nested stored procedure exists in the scope of its Snowflake Scripting block.
Benefits of nested stored procedures¶
Nested stored procedures provide the following benefits:
They can enhance and simplify security by encapsulating logic inside an anonymous block or parent stored procedure, which prevents access to it from outside the block or parent.
They keep code modular by splitting it logically into smaller chunks, which can make it easier to maintain and debug.
They improve maintainability by reducing the need for global variables or additional arguments, because a nested stored procedure can directly access the local variables of its block.
Usage notes for calling nested stored procedures¶
The following usage notes apply to calling a nested stored procedure:
To pass arguments to a nested stored procedure, a block can use constant values, Snowflake Scripting variables, bind variables, SQL (session) variables, and calls to user-defined functions.
When there is a mismatch between the data type of the value being passed in and the data type of an argument, Snowflake performs supported coercions automatically. For information about which coercions Snowflake can perform automatically, see Data type conversion.
Usage notes for variables in a nested stored procedure¶
The following usage notes apply to variables in a nested stored procedure:
A nested stored procedure can reference variables from its block that were declared before the nested stored procedure declaration in the DECLARE section of its block. It can’t reference variables declared after it in the DECLARE section.
A nested stored procedure can’t access variables declared in a LET statement in the BEGIN … END section of a block.
The value of a referenced variable reflects its value at the time when the nested stored procedure is called.
A nested stored procedure can modify a referenced variable value, and the modified value persists in the block and across multiple invocations of the same nested procedure in a single execution of its anonymous block or in a single call to its parent stored procedure.
The value of a variable that was declared before a nested stored procedure call can be passed as an argument to the nested stored procedure. The variable value can be passed as an argument in a call even if the variable was declared after the nested stored procedure declaration or in a LET statement.
For example, the following stored procedure declares several variables:
In this example, only var_before_nested_proc can be referenced in nested_sp_logic.
In the nested stored procedure call, the value of any of the following variables can be passed to the nested stored
procedure as an argument in var_name:
var_before_nested_procvar_after_nested_procvar_let_before_call
The value of var_let_after_call can’t be passed to the nested stored procedure as an argument.
Limitations for nested stored procedures¶
The following limitations apply to defining nested stored procedures:
They can’t be defined inside other nested stored procedures or inside control structures, such as FOR or WHILE loops.
Each nested stored procedure must have a unique name in its block. That is, nested stored procedures can’t be overloaded.
They don’t support output (OUT) arguments.
They don’t support optional arguments with default values.
The following limitations apply to calling nested stored procedures:
They can’t be called in an EXECUTE IMMEDIATE statement.
They can’t be called in asynchronous child jobs.
They don’t support named input arguments (
arg_name => arg). Arguments must be specified by position. For more information, see CALL.
Examples of nested stored procedures¶
The following examples use nested stored procedures:
Define a nested stored procedure that returns a scalar value
Define a nested stored procedure that calls another nested stored procedure
Define a nested stored procedure that returns tabular data¶
The following example defines a nested stored procedure that returns a tabular data. The example creates a
parent stored procedure called nested_procedure_example_table with a nested stored procedure
called nested_return_table. The code includes the following logic:
Declares a variable called
resof type RESULTSET.Includes the following logic in the nested stored procedure:
Declares a variable called
res2.Inserts values into a table called
nested_table.Sets the
res2variable to the results of a SELECT on the table.Returns the tabular data in the result set.
Creates the table
nested_tablein the parent stored procedure.Calls the nested stored procedure
nested_return_tableand sets theresvariable to the results of the call to the nested stored procedure.Returns the tabular results in the
resvariable.
Call the stored procedure:
Define a nested stored procedure that returns a scalar value¶
The following example defines a nested stored procedure that returns a scalar value. The example creates a
parent stored procedure called nested_procedure_example_scalar with a nested stored procedure
called simple_counter. The code includes the following logic:
Declares a variable called
counterof type NUMBER, and sets the value of this variable to0.Specifies that the nested stored procedure adds
1to the current value of thecountervariable.Calls the nested stored procedure three times in the parent stored procedure. The value of the
countervariable is carried over between invocations of the nested stored procedure.Returns the value of the
countervariable, which is3.
Call the stored procedure:
Define a nested stored procedure in an anonymous block¶
The following example is the same as the example in Define a nested stored procedure that returns a scalar value, except that it defines a nested stored procedure in an anonymous block instead of a stored procedure:
Define a nested stored procedure that is passed arguments¶
The following example defines a nested stored procedure that is passed arguments. In the example, the nested stored procedure inserts values into the following table:
The example creates a parent stored procedure called nested_procedure_example_arguments with a nested stored procedure
called log_and_multiply_numbers. The nested stored procedure takes two arguments of type NUMBER. The code includes the
following logic:
Declares variables
a,b, andxof type NUMBER.Includes a nested stored procedure that performs the following actions:
Inserts the two number values passed to it by the parent stored procedure into the
log_nested_valuestable using bind variables.Sets the value of variable
xto the result of multiplying the two argument values.Returns the value of
xto the parent stored procedure.
Sets the value of variable
ato5and variablebto10.Calls the nested stored procedure.
Returns the value of the
xvariable, which was set in the nested stored procedure.
Call the stored procedure:
Query the log_nested_values table to confirm that the nested stored procedure inserted the
values passed to it:
Define a nested stored procedure that calls another nested stored procedure¶
The following example defines a nested stored procedure that calls another nested stored procedure. The example creates a
parent stored procedure called nested_procedure_example_call_from_nested with two nested stored procedures
called counter_nested_proc and call_counter_nested_proc. The code includes the following logic:
Declares a variable called
counterof type NUMBER, and sets the value of this variable to0.Includes the nested stored procedure
counter_nested_procthat adds10to the value ofcounter.Includes the nested stored procedure
call_counter_nested_procthat adds15to the value ofcounterand also callscounter_nested_proc(which adds another10to the value ofcounter).Calls both nested stored procedures in the parent stored procedure.
Returns the value of the
countervariable, which is35.
Call the stored procedure:
Using and setting SQL variables in a stored procedure¶
By default, Snowflake Scripting stored procedures run with owner’s rights. When a stored procedure runs with owner’s rights, it can’t access SQL (or session) variables.
However, a caller’s rights stored procedure can read the caller’s session variables and use
them in the logic of the stored procedure. For example, a caller’s rights stored procedure
can use the value in a SQL variable in a query. To create a stored procedure that runs with
caller’s rights, specify the EXECUTE AS CALLER parameter in the
CREATE PROCEDURE statement.
These examples illustrate this key difference between caller’s rights and owner’s rights stored procedures. They attempt to use SQL variables in two ways:
Set a SQL variable before calling the stored procedure, then use the SQL variable inside the stored procedure.
Set a SQL variable inside the stored procedure, then use the SQL variable after returning from the stored procedure.
Both using the SQL variable and setting the SQL variable work correctly in a caller’s rights stored procedure. Both fail when using an owner’s rights stored procedure, even if the caller is the owner.
For more information about owner’s rights and caller’s rights, see Understanding caller’s rights and owner’s rights stored procedures.
Using a SQL variable in a stored procedure¶
The following example uses a SQL variable in a stored procedure.
First, set a SQL variable in a session:
Create a simple stored procedure that runs with caller’s rights and uses this SQL variable:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Call the stored procedure:
Set the SQL variable to a different value:
Call the procedure again to see that the returned value has changed:
Setting a SQL variable in a stored procedure¶
You can set a SQL variable in a stored procedure that’s running with caller’s rights. For more information, including guidelines for using SQL variables in stored procedures, see Caller’s rights stored procedures.
Note
Although you can set a SQL variable inside a stored procedure and leave it set after the end of the procedure, Snowflake does not recommend doing this.
The following example sets a SQL variable in a stored procedure.
First, set a SQL variable in a session:
Confirm the value of the SQL variable:
For example, the following stored procedure sets the SQL variable example_set_variable
to a new value and returns the new value:
Note: If you use Snowflake CLI, SnowSQL, the Classic Console, or the
execute_stream or execute_string method in Python Connector
code, use this example instead (see Using Snowflake Scripting in Snowflake CLI, SnowSQL, and Python Connector):
Call the stored procedure:
Confirm the new value of the SQL variable: