postgresql视图中可用->和->>提取jsonb字段，前者返回jsonb后者返回text；多层嵌套推荐#>和#>>；数组展开需lateral配合jsonb_array_elements()；高频路径须建表达式索引。
视图里直接用 -> 和 ->> 提取 JSONB 字段值
PostgreSQL 视图不支持“解构”语法（比如像 JavaScript 那样把 JSONB 自动展开成多列），但你可以用 -> 和 ->> 在 SELECT 列表里显式提取字段，效果接近解构。关键在于：结果类型不同——-> 返回 jsonb，->> 返回 text，后者更适合做排序、WHERE 比较或连接其他字符串字段。
常见错误是混用类型导致隐式转换失败，比如在 WHERE status->>'active' = true 中，右边是布尔值而左边是文本，必须写成 = 'true' 或用 ::boolean 显式转换。
-
->适合后续还要当 JSONB 处理的场景，比如嵌套再取data->'user'->'profile' -
->>更常用，尤其当字段要参与GROUP BY、ORDER BY或导出为 CSV 时 - 对空值要小心：
NULL->'x'返回NULL，但NULL->>'x'也返回NULL，不会报错
嵌套路径太深？用 #> 和 #>> 替代连续 ->
当 JSONB 结构是 {"meta": {"source": {"id": 123}}} 这类多层嵌套时，写 data->'meta'->'source'->'id' 不仅冗长，还容易漏括号或引号。这时 #> 和 #>> 是更稳的选择，它们接受路径数组，一次定位。
例如：data#>'{meta,source,id}' 等价于 data->'meta'->'source'->'id'，但少写三个 ->，也避免了中间某层为 null 时整个链式调用提前中断的问题（#> 同样返回 NULL，行为一致）。
-
#>返回jsonb，#>>返回text，和->/->>对应 - 路径数组里不能有变量，只能是字面量字符串，所以没法动态拼接键名
- 如果路径中某个 key 不存在，整条表达式返回
NULL，不会报错
视图里展开 JSONB 数组要用 jsonb_array_elements()
视图是只读的，不能用 CTE 或子查询临时展开数组再 JOIN —— 除非你用 LATERAL。而最直接的方式是在视图定义里用 jsonb_array_elements() 配合 LATERAL，把一个 JSONB 数组字段“炸开”成多行。
比如有个 products 表，specs 是 jsonb 类型存着规格数组 [{"size":"S","stock":10},{"size":"M","stock":20}]，你想在视图里让每条规格单独一行：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
CREATE VIEW product_specs AS SELECT id, spec->>'size' AS size, (spec->>'stock')::int AS stock FROM products, LATERAL jsonb_array_elements(specs) AS spec;
注意点：
- 没加
LATERAL会报错，因为jsonb_array_elements()依赖外层表的specs字段 - 每个数组元素变成一行，原表一行可能对应视图多行，
COUNT(*)会变大 - 如果
specs是NULL或空数组，LATERAL不产生任何行（类似INNER JOIN）；需要保留原行就改用LEFT JOIN LATERAL
别忘了给视图里高频查询的 JSONB 路径建索引
视图本身不存数据，但底层表的索引依然生效。如果你在视图里大量用 data->>'status' 做 WHERE 条件，就得在原表上给这个路径建表达式索引，否则每次查询都要全表扫描 JSONB 字段。
例如：
CREATE INDEX idx_orders_status ON orders ((data->>'status'));
或者更精确地针对嵌套路径：
CREATE INDEX idx_orders_user_id ON orders ((data#>>'{user,id}'));
关键提醒：
- GIN 索引适合
@>、?、?|这类存在性判断；B-tree 适合=、、<code>BETWEEN等精确或范围查询 - 索引表达式必须和视图里写的完全一致，包括单双引号、大小写、空格（虽然 PG 通常忽略空格，但保险起见别加）
- 建完索引后用
EXPLAIN确认是否命中，因为优化器有时会因统计信息不准而放弃使用
真正容易被忽略的是：视图定义里看似简单的 ->> 提取，一旦没索引，随着数据量增长，性能会断崖式下跌——它不像普通字段那样自动享受 B-tree 加速。
