pgJDBC 查询 JSONB 问号运算符时报参数未绑定

同一条 JSONB 查询在 PostgreSQL 客户端里能执行，放进 Java 的 PreparedStatement 后却报 No value specified for parameter 1。如果 SQL 含有 ?、?| 或 ?& 运算符，应先检查驱动是否把运算符中的问号也当成了参数占位符。

这里限定当前 pgJDBC 的原生 JDBC 调用。ORM、SQL 模板引擎或其他 PostgreSQL 驱动可能还会先处理 SQL，不能把 pgJDBC 的转义写法不加区分地搬到所有执行入口。

区分运算符与真正的值参数

在 PostgreSQL SQL 中，下面的问号是 JSONB 顶层存在性运算符：

SELECT '{"status":"ready"}'::jsonb ? 'status';

预期结果为真。? 检查顶层对象键或数组字符串元素，不会递归查找任意深度的键。

但在 PreparedStatement 的 SQL 字符串中，单个问号表示需要绑定的位置参数。如果直接复制上面的 SQL，驱动可能要求一个根本不应存在的参数。报错也可能来自真正漏绑的参数，因此需要同时核对 SQL 结构与 setXxx 调用，不能见到这条错误就全部替换问号。

只转义运算符中的问号

pgJDBC 使用 ?? 保留一个作为运算符的问号。实际值参数仍写单个 ?，继续通过绑定传入：

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class JsonbKeyCheck {
    public static boolean containsTopLevelKey(
            Connection connection, String json, String key)
            throws SQLException {
        String sql = "SELECT CAST(? AS jsonb) ?? CAST(? AS text)";
        try (PreparedStatement statement = connection.prepareStatement(sql)) {
            statement.setString(1, json);
            statement.setString(2, key);
            try (ResultSet result = statement.executeQuery()) {
                if (!result.next()) {
                    throw new SQLException("expected one result row");
                }
                boolean found = result.getBoolean(1);
                if (result.wasNull()) {
                    throw new SQLException("unexpected SQL NULL result");
                }
                return found;
            }
        }
    }
}

示例要求已有可用的 JDBC 连接，使用 Java 7 之后的资源管理语法，不负责创建连接或提交事务。传入合法 JSON 文本 {"status":"ready"} 和键名 status 时，预期返回 true；换成不存在的键名时预期返回 false。

这条 SQL 只有两个值参数，中间 ?? 不需要绑定。不要把两个真正的参数也改成 ??，更不要为满足错误提示而凭空增加一次 setString。

另外两种运算符同样只把问号部分转义：在 pgJDBC SQL 字符串中，?| 写成 ??|，?& 写成 ??&。原有右操作数仍需是相应的 text[]，转义不会替你解决类型或参数绑定错误。

转义只属于对应的客户端入口

直接在 psql 中执行 SQL 时，应保留 PostgreSQL 原生的单问号运算符。?? 是 pgJDBC 处理 SQL 时的转义，不是给服务器定义了一个新的 JSONB 运算符。

如果应用还经过查询构造器，检查最终交给 JDBC 的 SQL 及参数个数；只记录必要的结构信息，不把 JSON 内容或敏感参数写进公开日志。不同层都做一次转义，反而可能把 SQL 改坏。

不要为了绕过解析改用字符串拼接外部值。保留 PreparedStatement 和参数绑定，可以把修复限定在运算符写法。改成其他函数形式则需要重新核对查询语义和执行计划，不能假定与原索引路径完全相同。

修复后通过实际应用调用链检查存在的键、不存在的键以及仅存在于嵌套对象中的同名键；后者不应被顶层 ? 当作存在。保留原 SQL 模板便于回退，修复只涉及只读查询，不需要迁移 JSONB 数据或重建索引。