为何Linux DB2存储过程中的静态SQL被编译器拒绝？

在Linux环境的DB2存储过程中，看到大量静态SQL的用法，但自己编写如下静态SQL时：

SET v_MsgText = 'DROP LOC CHECK failed.';

ALTER TABLE LIBRAT.APNVEND_RECORD_APNV_LOC_DATA 
    DROP CONSTRAINT LIBRAT_APNVEND_RECORD_APNV_LOC_DATA_C1;

编译器抛出错误：

Error: DB2 SQL Error: SQLCODE=-104, SQLSTATE=42601, SQLERRMC=ALTER;C CHECK failed.';

;TRUNCATE, DRIVER=4.33.31

SQLState: 42601

ErrorCode: -104

Error occurred in:

CREATE or REPLACE PROCEDURE LIBRAT.TCVISION_RELOAD_APNVEND...

必须改用动态SQL的方式才能正常执行：

SET v_MsgText = 'DROP LOC CHECK failed.';
SET v_SqlStmt = 'ALTER TABLE LIBRAT.APNVEND_RECORD_APNV_LOC_DATA DROP CONSTRAINT LIBRAT_APNVEND_RECORD_APNV_LOC_DATA_C1';

EXECUTE IMMEDIATE v_SqlStmt;

DB2存储过程对静态SQL和动态SQL的支持范围有明确限制：

• 静态SQL在存储过程编译阶段就会完成绑定，仅支持不会修改数据库对象结构的语句，比如DML（SELECT/INSERT/UPDATE/DELETE）以及部分系统查询类语句。这类语句不会改变数据库对象的元数据，编译时的绑定信息在运行时能保持一致。
• 你使用的ALTER TABLE DROP CONSTRAINT属于DDL（数据定义语言），这类语句会直接修改数据库对象的结构，会破坏静态SQL绑定的一致性——编译时的表结构和运行时可能因为DDL操作发生变化，因此DB2禁止在存储过程中直接用静态SQL执行DDL。
• 动态SQL（EXECUTE IMMEDIATE方式）是在运行时才解析执行，能适配DDL带来的对象结构变化，所以必须用这种方式执行DDL语句。

你看到的示例中的静态SQL，基本都是DML类语句，而非DDL，因此可以直接静态编写。

内容的提问来源于stack exchange，提问作者Dave Clark