为何PostgreSQL不允许使用绑定参数定义物化视图？

咱们先从PostgreSQL的设计逻辑入手，把核心问题拆解清楚：

1. PostgreSQL对物化视图的限制原因 #

你定位到的源码注释已经点明了关键：

/* A materialized view would either need to save parameters for use in maintaining/loading the data or prohibit them entirely. The latter seems safer and more sane. */

物化视图的本质是预计算并存储查询结果的物理表，后续执行REFRESH MATERIALIZED VIEW时，必须完全复用最初的查询逻辑来更新数据。如果允许绑定参数，PostgreSQL会陷入两难：

• 要么永久保存创建时的参数值，这会增加元数据复杂度，还容易出现参数丢失、刷新逻辑不一致的问题
• 要么放弃复用原查询，这违背了物化视图的设计初衷

所以PostgreSQL选择了最稳妥的方案：直接禁止在物化视图定义中使用任何绑定参数。源码里的query_contains_extern_params函数就是用来检测这类参数的，一旦发现就抛出FEATURE_NOT_SUPPORTED错误。

2. Ecto两种写法的本质差异 #

第一种写法（报错）： #

Repo.query("CREATE MATERIALIZED VIEW $1 AS SELECT * FROM tasks WHERE resource_type = $2 AND task_type = $3 ", [view_name, resource_type, task_type])

这里的$1、$2、$3是PostgreSQL层面的绑定参数——Ecto会把SQL模板和参数分开发送给数据库，由PostgreSQL服务器完成参数替换。但数据库在解析物化视图定义时，检测到了这些参数，直接触发了上面说的限制。

第二种写法（正常工作）： #

Repo.query("CREATE MATERIALIZED VIEW \"#{view_name}\" AS SELECT * FROM tasks WHERE resource_type = '#{resource_type}' AND task_type = '#{task_type}' ", [])

这是Elixir客户端层面的字符串插值：在SQL发送到数据库之前，Elixir已经把所有变量的值直接拼进了SQL字符串里。PostgreSQL收到的是一条完全没有绑定参数的完整定义，自然能正常执行。

安全提醒：避免SQL注入 #

直接字符串插值存在严重的SQL注入风险！如果view_name、resource_type等值来自用户输入，恶意攻击者可以构造特殊值执行任意SQL。更安全的做法是用Ecto提供的工具转义标识符和值：

# 安全转义标识符（如视图名）
safe_view_name = Ecto.Adapters.SQL.quote(Repo, view_name)
# 安全转义字符串值
safe_resource_type = Ecto.Adapters.SQL.escape(Repo, resource_type)
safe_task_type = Ecto.Adapters.SQL.escape(Repo, task_type)

# 拼接成安全的SQL并执行
Repo.query("CREATE MATERIALIZED VIEW #{safe_view_name} AS SELECT * FROM tasks WHERE resource_type = #{safe_resource_type} AND task_type = #{safe_task_type}", [])

这样既符合PostgreSQL的要求，又能彻底避免注入风险。

内容的提问来源于stack exchange，提问作者Bruno Antunes