应优先使用 jsonb_path_query 提取多层嵌套字段，因其路径表达清晰、容错性强；链式 -> 易因某级 null 或类型错误静默返回 null，且不支持通配符和条件过滤。
用 jsonb_path_query 代替链式 -> 提取多层嵌套字段
当字段藏在三层以上结构里（比如 {"meta": {"user": {"profile": {"id": 123}}}}），硬写 data->'meta'->'user'->'profile'->>'id' 容易漏掉某一级 null 或类型错，结果静默返回 null。用 jsonb_path_query 一次写清路径更可靠。
- 路径必须以
$开头，数组末尾加[*]才能展开：例如$.meta.user.profile.id返回单个值，$.meta.user.tags[*]返回每个 tag 行 - 字符串字面量用单引号：
$.user.profile.lang ? (@ == 'zh-CN')，不是双引号 - 返回的是
jsonb类型，要文本值得再套->>或::text，否则 WHERE 匹配会失败 - 不走 GIN 索引，高频查询别直接放 WHERE 里，先物化到普通列更稳
用 -> 和 ->> 取数组元素时索引从 0 开始且越界不报错
对 JSONB 数组取第 N 个元素，别绕路用 jsonb_extract_path；-> 和 ->> 更直接、更常用。
-
meta->'tags'->0返回"pg"（jsonb 类型），还能继续链式解析；meta->'tags'->>0返回pg（text 类型），适合拼接或 LIKE 匹配 - 负数索引取末尾：
meta->'tags'->>-1是最后一个元素 - 空数组、路径不存在、索引越界都返回 SQL
null，不是错误——但->>对 null 字段会返回字符串'null'，WHERE 里容易误判 - 别写
meta->'tags'[0]或meta->'tags'.0，语法错误
别用 jsonb_extract_path 做动态或带条件的提取
它只认死路径，一碰变量、通配符、过滤表达式就报 U0600008 错误，尤其在 GaussDB 或 UGO 迁移环境里很常见。
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 合法调用只有像
jsonb_extract_path(data, 'user', 'profile', 'lang')这种全静态 text 参数 - 传
'tags[*]'、'hobbies[?(@ == "reading") ]'、或拼接变量如'user.' || col_name都会炸 - 中间任意一级是 null 或非对象，整条返回 null，无提示；想排查哪层断了，得靠
jsonb_typeof()逐级查 - 性能略优于链式
->，但仅限路径完全确定的场景；否则直接切到jsonb_path_query
用 jsonb_to_recordset 摊平同构数组时类型声明必须严格匹配
面对 {"orders": [{"id": 1, "amt": 100}, {"id": 2, "amt": 200}]} 这类结构，想转成关系行再 JOIN，jsonb_to_recordset 比手动 jsonb_array_elements + jsonb_populate_record 更简洁。
- 类型声明里写
id int, amt numeric，不能写id integer—— PostgreSQL 对类型名大小写和别名敏感，错一个字段整行丢弃（静默） - 数组为空或为 null 时函数返回空结果集，主表记录会被 LEFT JOIN 以外的 JOIN 丢掉，必要时补
LEFT JOIN LATERAL ... ON true - 别在 WHERE 里对展开字段做复杂计算（比如
amt * rate > 100），planner 容易误估行数；先过滤原 JSONB 再展开更安全
真正麻烦的是路径深度和数据一致性混合出现的场景：比如某条记录 user 是对象，另一条却是 null 或字符串，jsonb_path_query 能穿透，但 -> 链会断；而 jsonb_to_recordset 对字段名错位完全不提醒。这些边界情况得靠测试数据覆盖，不能只看文档示例。
