SQLAlchemy JSONB path_match 报 jsonb @@ character varying

查询 PostgreSQL JSONB 时，调用 path_match() 或 path_exists()，却收到 operator does not exist: jsonb @@ character varying 一类错误。JSON 文档合法，路径表达式也没明显问题，生成 SQL 的右侧参数却被 CAST 成了 VARCHAR。

@@、@? 的右侧需要 JSONPath 类型。SQLAlchemy 的受影响实现把字符串路径按普通字符串参数处理；使用会渲染绑定类型 CAST 的 PostgreSQL 驱动时，这个类型错误更明显。继续改 JSONB 列为 text，或给文档额外加引号，都没有修正运算符参数类型。

更新修补，或明确路径参数类型

SQLAlchemy 2.0.46 包含相关修复，path_match()、path_exists() 会为右侧选择 JSONPath 类型。更新到包含修补且适合项目的版本后，先检查原查询生成的 SQL，确认不再把该操作数错误地转成 VARCHAR。不必要求每种驱动都生成相同的显式 CAST 文本。

旧环境暂时不能更新时，可以按表达式类型明确右侧：

from sqlalchemy import select, type_coerce
from sqlalchemy.dialects.postgresql import JSONB

stmt = select(Product).where(
    Product.attributes.path_match(
        type_coerce("$.size.height == 150", JSONB.JSONPathType)
    )
)

Product.attributes 在这里是应用已映射的 JSONB 列。type_coerce() 指明 SQLAlchemy 应如何处理这个表达式，不是在 Python 中执行 JSONPath，也不是把整个 JSON 文档转换成另一种存储格式。

不要将外部输入塞进 literal_column()，只为了去掉绑定参数的类型 CAST。那会放弃值参数化。动态路径和变量应按自己的 JSONPath 语法及参数契约构造，仍须核对实际条件是否符合业务意图。

区分匹配谓词和路径存在检查

path_match() 与 path_exists() 表达的条件不同：前者使用 @@ 检查 JSONPath 谓词结果，后者使用 @? 检查路径是否产生结果。类型修复不会替调用方选对运算符。

验收时用已知 JSON 文档同时准备应匹配和不应匹配的记录，比较返回行数及目标字段。只确认数据库不再抛“运算符不存在”，可能漏掉条件语义错误。

如果错误提到其他运算符，或者生成 SQL 的右侧已经是正确的 JSONPath 类型，应继续检查 PostgreSQL 版本、路径语法和实际数据。这项修补针对右侧绑定类型，不是通用的 JSON 查询修复；它也不同于 JSONB 文本提取带引号或 JDBC 问号占位符冲突的问题。