jsonb_extract_path仅适用于静态确定路径提取，不支持动态路径、通配符或过滤表达式；需用jsonb_path_query替代复杂查询，且多参数版本在GaussDB等环境易报U0600008错误。
jsonb_extract_path 做动态路径或带条件的提取——它只认“确定路径”，不支持 *、数组下标通配、过滤表达式（如 [?(@ > 10)]），否则在 GaussDB 或 UGO 迁移时会报 U0600008: jsonb_extract_path 函数不支持 XXX 作为参数。
什么时候该用 jsonb_extract_path，而不是 jsonb_path_query
当你明确知道要取哪一层、哪个 key、哪个数组索引，且路径是静态字符串时，jsonb_extract_path 是轻量、高效的选择。比如从 {"user": {"profile": {"lang": "zh-CN"}}} 中取 user.profile.lang。
- 路径必须是
text类型的多个参数，例如jsonb_extract_path(data, 'user', 'profile', 'lang') - 不能传入变量拼接的路径字符串（如
'user.' || lang_col），那得用jsonb_path_query+$变量绑定 - 如果字段是
json类型（非jsonb），必须先显式强转：data::jsonb，否则函数找不到匹配签名
jsonb_extract_path 和 ->/#> 的实际差异在哪
三者都能按路径取值，但语义和类型安全不同：
-
->和->>只能一层一级链式调用，适合简单结构；写成data->'user'->'profile'->>'lang'看似清晰，但中间任意一级为null或非对象，整条链就返回null，无提示 -
#>和#>>接收text[]路径（如'{user,profile,lang}'），原子性更强：路径错一位或越界，也只返回null，不会报错 -
jsonb_extract_path行为与#>高度一致，但参数是可变个数的text，更易读；它底层仍走二进制解析，性能略优于纯操作符链（尤其深嵌套）
示例对比：
SELECT
data #> '{user,profile,lang}' AS op_hash,
jsonb_extract_path(data, 'user', 'profile', 'lang') AS func_call
FROM (SELECT '{"user": {"profile": {"lang": "zh-CN"}}}'::jsonb AS data) t;
为什么 jsonb_extract_path_text 比 jsonb_extract_path 更常用
绝大多数业务场景要的是「字符串值」，不是带双引号的 JSON 字符串。比如取用户昵称、城市名、状态码——直接用 jsonb_extract_path_text，省去后续 ::text 转换，也避免 "John"（JSON 字符串）和 John（纯文本）混淆。
-
jsonb_extract_path返回jsonb类型，若后面接WHERE name = 'John'，会隐式转 text，但可能触发慢查询（尤其没索引时） -
jsonb_extract_path_text直接返回text，可直接参与=、ILIKE、IN等比较，也方便加函数索引（如CREATE INDEX ON users ((jsonb_extract_path_text(profile, 'city')))） - 注意：如果原 JSON 中该路径值是数字或布尔，
_text版本会转成对应字符串（42 → '42',true → 'true'），需确认业务是否接受
迁移或跨库时最容易踩的坑
PostgreSQL 原生支持 jsonb_extract_path，但 GaussDB、某些云厂商兼容层或旧版 UGO 工具只认 jsonb_extract_path 的两参数简化版（即只支持 jsonb_extract_path(data, path)），多于两个参数就报 U0600008 错误。
- 查当前环境是否真支持多参数：运行
SELECT jsonb_extract_path('{"a": {"b": 1}}'::jsonb, 'a', 'b');，若报错则说明被阉割了 - 临时绕过：改用
#>操作符，如data #> ARRAY['a','b']，语义等价且兼容性更好 - 长期方案：统一用
jsonb_path_query+$variable，虽然语法稍重，但可表达$.a.b、$.items[*].name等复杂逻辑，且主流兼容层都支持
真正难处理的从来不是语法，而是路径本身是否稳定——一旦上游 JSON 结构松散（比如 "address" 有时是对象、有时是数组、有时缺失），所有基于固定路径的函数都会静默返回 null，而你很难在 SQL 层做防御性检查。这时候不如把清洗逻辑交给应用层，数据库只存原始 jsonb，用 @> 做存在性判断更可靠。
