hstore()不支持record/row类型，仅接受text[]键值交错数组或两个等长text[]；需显式转换字段并确保类型对齐，或用PostgreSQL 14+的json_to_hstore()替代，但注意大小写丢失与NULL处理问题。
hstore() 函数只能接受键值对数组或两个等长数组，不能直接传入行
很多人尝试 hstore(my_table.*) 或 hstore(ROW(col1, col2))，结果报错 function hstore(record) does not exist。PostgreSQL 的 hstore() 没有直接支持 record/row 类型的重载版本——它只认 text[]（键值交错数组）或 text[], text[]（键数组和值数组）。
正确做法是显式展开字段，并确保键名和值一一对应：
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 的方式存。
