PROCEDURE CALL

Translation reference for PROCEDURE CALL aka SUBPROGRAM INVOCATION

Description

This section describes the syntax for subprogram invocations within PL blocks, such as procedures or anonymous blocks.

For more information on this subject, please refer to Oracle's Subprogram documentation: (Oracle PL/SQL Language Reference Subprogram Invocation Statement)

Procedure calls can be migrated to Snowflake as long as there are no optional parameters and their order matches the formal parameters. Please note that Procedure invocations get migrated to a Call statement.

Oracle Subprogram Invocation Syntax

<subprogram invocation> := subprogram_name [ ( [ parameter [, parameter]... ] ) ]

<parameter> := {
  <actual parameter>
  | <formal parameter name> => <actual parameter>
  }

Snowflake Scripting has support for this statement, albeit with some functional differences.

Snow Scripting Subprogram Invocation Syntax

<subprogram invocation> := CALL subprogram_name [ ( [ parameter [, parameter]... ] ) ]

<parameter> := {
  <actual parameter>
  | <formal parameter name> => <actual parameter>
  }

Sample Source Patterns

Consider the next table and procedure for the examples below.

Oracle

CREATE TABLE procedure_call_test_table(
    col1 INTEGER
);

-- Simple Called procedure
CREATE OR REPLACE PROCEDURE called_procedure (param1 INTEGER)
AS
BEGIN
    INSERT INTO procedure_call_test_table VALUES (param1);
END;

Snowflake

Simple call

Oracle

Query

CREATE OR REPLACE PROCEDURE simple_calling_procedure
AS
BEGIN
    called_procedure(1);
END;

CALL simple_calling_procedure();

SELECT * FROM procedure_call_test_table;

Result

Snowflake Scripting

Query

CREATE OR REPLACE PROCEDURE PUBLIC.simple_calling_procedure ()
RETURNS VARCHAR
LANGUAGE SQL
EXECUTE AS CALLER
AS
$$
   BEGIN
      CALL called_procedure(1);
   END;
$$;

CALL PUBLIC.simple_calling_procedure();

SELECT * FROM PUBLIC.procedure_call_test_table;

Result

Calling a procedure with an optional parameter

This sample contains manual intervention for some functional differences and is used to explain them. For more information on these differences, please check the Known Issues section below.

Oracle

Query

-- Procedure with optional parameters
CREATE OR REPLACE PROCEDURE proc_optional_parameters (param1 INTEGER, param2 INTEGER := 8, param3 INTEGER)
AS
BEGIN
    INSERT INTO procedure_call_test_table VALUES (param1);
    INSERT INTO procedure_call_test_table VALUES (param2);
    INSERT INTO procedure_call_test_table VALUES (param3);
END;

CREATE OR REPLACE PROCEDURE calling_procedure
AS
BEGIN
    -- positional convention
    proc_optional_parameters(1, 2, 3);
    
    -- named convention
    proc_optional_parameters(param1 => 4, param2 => 5, param3 => 6);
    
    -- named convention, second gets ommited
    proc_optional_parameters(param1 => 7, param3 => 9);
    
    -- named convention, different order
    proc_optional_parameters(param3 => 12, param1 => 10, param2 => 11);
END;

CALL calling_procedure();

SELECT * FROM procedure_call_test_table;

Result

Snowflake Scripting

Query

-- Procedure with optional parameters
CREATE OR REPLACE PROCEDURE PUBLIC.proc_optional_parameters (param1 INTEGER, param2 INTEGER, param3 INTEGER)
RETURNS VARCHAR
LANGUAGE SQL
EXECUTE AS CALLER
AS
$$
   BEGIN
      INSERT INTO PUBLIC.procedure_call_test_table VALUES (:param1);
      INSERT INTO PUBLIC.procedure_call_test_table VALUES (:param2);
      INSERT INTO PUBLIC.procedure_call_test_table VALUES (:param3);
   END;
$$;

CREATE OR REPLACE PROCEDURE PUBLIC.calling_procedure ()
RETURNS VARCHAR
LANGUAGE SQL
EXECUTE AS CALLER
AS
$$
   BEGIN
      -- positional convention
      CALL proc_optional_parameters(1, 2, 3);
      
      -- named convention
      CALL proc_optional_parameters(param1 => 4, param2 => 5, param3 => 6);
      
      -- named convention, second gets ommited, causes error
      --CALL proc_optional_parameters(param1 => 7, param3 => 9);
      -- manual filling
      CALL proc_optional_parameters(param1 => 7, param2 => 8, param3 => 9);
      
      -- named convention, different order, causes wrong order in output
      -- CALL proc_optional_parameters(param3 => 12, param1 => 10, param2 => 11)
      -- manual reordering
      CALL proc_optional_parameters(param1 => 10, param2 => 11, param3 => 12);
   END;
$$;

CALL PUBLIC.calling_procedure();

SELECT * FROM PUBLIC.procedure_call_test_table;

Result

Known Issues

1. Calling Subprograms with default values is not supported

Snowflake does not support setting default values for parameters. So these will need to be filled into every call.

2. Named parameters are accepted, but not functionally equivalent

These parameters will not cause any compilation errors when run in Snowflake; however, calls still place them in a positional manner. For this reason, the order of these parameters needs to be checked. SnowConvert does not support checking nor reordering these parameters.

3. Calling Subprograms with Out Parameters is not supported

Snowflake does not have support for parameter modes, however, a solution is being implemented to emulate their functionality. To get more information about the transformation for output parameters please go to the following article Output Parameters.

Related EWIs

1. MSCEWI1058: Functionality is not currently supported by Snowflake Scripting

2. MSCEWI1078: Output parameters are not supported by Snowflake Scripting