postgresql中xpath提取xml属性值必须用@前缀，如xpath('//node/@attr', xml_col)，否则返回空数组；属性含连字符需写为@'data-id'；结果为xml[]数组，须用[1]或unnest()提取；命名空间需显式声明；推荐用生成列+索引优化性能。
PostgreSQL里用xpath提取XML属性值，必须加@前缀
直接写xpath('//node/@attr', xml_col)才能拿到属性，写成xpath('//node/attr', xml_col)会返回空数组——后者是找子元素，不是属性。这是最常卡住人的地方。
PostgreSQL的xpath函数严格区分元素和属性，XML规范里@就是属性标识符，数据库不会帮你“猜”。
- 属性必须显式用
@attr，不能省略@ - 如果属性名含连字符（如
data-id），得用单引号包起来：@'data-id' - 返回结果是
xml[]数组，即使只匹配一个值，也要用[1]取出来或unnest()展开
xpath返回空数组的三个常见原因
不是SQL写错了，而是XML结构或命名空间没对上。
- XML有默认命名空间（
xmlns="http://example.com"），但xpath默认不识别——得在第二个参数里显式声明，比如xpath('//book/@isbn', xml_col, ARRAY[ARRAY['x', 'http://example.com']]) - 大小写敏感：XML里是
<author></author>，XPath写//author就查不到 - 文本节点里混了空白：用
normalize-space()包裹，比如xpath('normalize-space(//title/text())', xml_col)
提取多个同名属性时，unnest()比数组下标更安全
用[1]取第一个容易报错——万一没匹配到，数组为空，[1]会返回NULL；而业务上可能需要明确区分“无匹配”和“值为NULL”。
更稳的做法是用unnest()配合LATERAL：
SELECT id, attr_val
FROM docs
CROSS JOIN LATERAL unnest(xpath('//item/@status', doc_xml)) AS t(attr_val);
- 没匹配到任何
@status，这行就不输出，不会留NULL占位 - 每个匹配值单独成行，方便后续聚合或过滤
- 避免在WHERE里写
xpath(...) != '{}'::xml[]这类难读又低效的判断
性能注意：别在WHERE里反复调用xpath
每次调用xpath都要解析整段XML，如果表大、XML长，查询会明显变慢。
- 高频查询的属性，建议建生成列：
ALTER TABLE docs ADD COLUMN status text GENERATED ALWAYS AS (xpath('//item/@status', doc_xml)::text[]) [1]::text) STORED; - 然后给该列建索引：
CREATE INDEX idx_docs_status ON docs(status); - XML内容更新不频繁时，这种预计算收益远大于实时解析开销
命名空间处理、空数组边界、生成列缓存——这三个点漏掉任意一个，都可能让XPath从“能用”变成“不敢上线”。
