如何用HSTORE函数在PostgreSQL中将行记录转换成键值对格式？

本文共计807个文字，预计阅读时间需要4分钟。

许多人在尝试使用 `hstore(my_table.*)` 或 `hstore(ROW(col1, col2))` 时遇到错误：

正确做法是显式展开字段，并确保键名和值一一对应：

SELECT hstore(ARRAY['id', 'name', 'active'], ARRAY[ id::text, name, active::text ]) FROM users LIMIT 1;

注意类型对齐：所有值必须是 text，布尔、数字、时间等需显式转成字符串，否则会报 array must have even number of elements 或类型不匹配错误。

用 json_to_hstore() 替代手动拼接，但仅限 PostgreSQL 14+

如果你用的是 PostgreSQL 14 或更新版本，json_to_hstore() 是更安全的选择，它能自动处理 NULL、布尔、数字等类型转换：

SELECT json_to_hstore(row_to_json(t)::jsonb) FROM (SELECT 1 AS id, 'Alice' AS name, true AS active) t;

但要注意：row_to_json() 生成的 JSON 键名全为小写，且无法控制字段顺序；如果原表有大小写混合列名（如 "UserId"），会被转成 "userid"，丢失大小写信息。

常见陷阱：

• json_to_hstore(null) 返回 NULL，不是空 hstore
• JSON 中的 null 值在 hstore 中变成缺失键，不是 NULL 值本身
• 嵌套对象或数组会被转成 JSON 字符串，不是扁平键值对

批量转换整张表时，避免逐行调用 hstore() 导致性能下降

对大表执行 SELECT hstore(ARRAY[...], ARRAY[...]) FROM big_table 看似简洁，但每行都要构造两个数组、做类型转换，CPU 开销明显高于纯列扫描。实测百万行下比等价的 jsonb_object() 慢 20%–30%。

推荐方案：

• 优先考虑是否真需要 hstore：多数场景用 jsonb 更通用、索引能力更强
• 若必须用 hstore 且字段固定，提前建好函数封装转换逻辑，避免重复写 ARRAY 表达式
• 导出场景可改用 COPY (SELECT ... ) TO ... WITH (FORMAT csv) + 外部脚本处理，避开数据库内复杂转换

hstore 转换后无法直接当 JSON 用，跨格式互操作要小心类型丢失

hstore 本质是键值字符串对集合，没有类型概念：布尔 true、整数 42、NULL 都存成字符串。从 hstore 再转回结构化数据时，必须额外维护类型元信息，否则 (my_hstore -> 'age')::int 在值为空或非数字时直接报错。

典型翻车点：

• hstore('a=>1,b=>true,c=>NULL') → hstore 里只有 a 和 b 两个键，c 被丢弃
• hstore_to_json() 把所有值当字符串输出，不会还原原始类型
• 用 -> 取值后不做空值判断就强转，容易触发 invalid input syntax for integer

真正需要保留类型语义时，别硬套 hstore，老实用 jsonb 或带 schema 的方式存。