可行，但需显式声明字段名和类型：jsonb_to_record用于单对象，jsonb_to_recordset配合LATERAL用于数组，嵌套结构宜先用#>>/#>提取子对象再映射，且须建表达式索引并校验JSONB结构一致性。
直接用 jsonb_to_record 或 jsonb_to_recordset 在视图中做结构化映射是可行的，但必须明确：视图定义里不能动态推断 JSONB 字段结构，所有输出列名和类型必须显式声明，否则会报错 ERROR: column definition list is required。
视图中用 jsonb_to_record 显式声明字段结构
这个函数把单个 JSONB 对象转成一行记录，但前提是你要提前知道字段名和类型。比如 data 字段存着 {"name":"Alice","score":95.5,"active":true}，那视图就得写死列定义：
CREATE VIEW users_flat AS
SELECT id, name, data->>'name' AS real_name,
(jsonb_to_record(data) AS r(name text, score numeric, active boolean)).*
FROM users;注意三点：
-
jsonb_to_record(data)后面必须跟AS r(...)，括号里是完整字段名+类型列表，一个都不能少 - 返回的列会覆盖前面 SELECT 中同名字段（比如这里
name被r.name覆盖），命名冲突要提前规避 - 如果
data是 NULL 或结构不匹配（比如缺score字段），对应列返回 NULL，不会报错，但类型强制转换可能失败（如"abc"强转numeric）
处理 JSONB 数组需改用 jsonb_to_recordset + LATERAL
当 JSONB 是数组（如 [{"item":"A","qty":2},{"item":"B","qty":1}]），jsonb_to_record 不适用，必须用 jsonb_to_recordset 并配合 LATERAL 展开：
CREATE VIEW orders_items AS SELECT o.id AS order_id, r.* FROM orders o, LATERAL jsonb_to_recordset(o.items) AS r(item text, qty integer);
关键点：
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
-
LATERAL是必须的，它让右边能引用左边的o.items；去掉就报错invalid reference to FROM-clause entry -
jsonb_to_recordset同样要求显式定义返回结构，且只接受 JSONB 数组，传对象会报错cannot call jsonb_to_recordset on a scalar - 空数组
[]展开后无行，整条父记录在视图中消失；需要保留父记录得用LEFT JOIN LATERAL ... ON true
嵌套结构太深？先用 #>/#>> 提取再映射
如果原始 JSONB 嵌套很深（如 {"response":{"data":{"user":{"id":101,"role":"admin"}}}}），硬塞进 jsonb_to_record 的参数里既难读又易错。更稳的做法是先用路径操作符提取子对象，再映射：
CREATE VIEW users_role AS
SELECT id,
(jsonb_to_record(data#>'{response,data,user}')
AS r(id integer, role text)).*
FROM api_logs;好处很明显：
-
data#>'{response,data,user}'返回jsonb类型，哪怕中间某层是NULL，结果也是NULL，不会中断整个表达式 - 避免了
data->'response'->'data'->'user'这种链式写法中任一环节为NULL就全链失效的问题 - 路径数组
{response,data,user}是字面量，不能含变量，所以无法用于动态 key 场景
性能与索引注意事项
视图本身不存数据，但每次查询都会重执行底层逻辑。高频使用的 JSONB 映射字段，务必加表达式索引：
CREATE INDEX idx_users_name ON users ((data->>'name'));
另外要注意：
-
jsonb_to_record和jsonb_to_recordset都是 volatile 函数，无法被物化视图或部分查询优化器跳过 - 如果 JSONB 结构不稳定（比如某些记录多一个字段），显式定义的类型可能出错，生产环境建议加
WHERE data ? 'required_field'过滤 - 千万级表上用这些函数做 JOIN，性能瓶颈往往不在函数本身，而在缺乏合适的表达式索引或统计信息不准
最常被忽略的是：视图定义里写的类型必须和实际 JSONB 内容严格一致，比如数字字段存了 "123" 字符串，定义成 integer 就会静默转成 NULL，而不是报错——查不到数据时先检查这个。
