pg_restore 只恢复指定表时报 type hstore does not exist

同一份归档，整库恢复正常，加上 pg_restore -t 只恢复部分表却在建表阶段失败：

ERROR: type "hstore" does not exist

如果失败 SQL 中有 hstore 列，先检查目标库是否已经安装提供这个类型的扩展。pg_restore --table 选择表，并不会自动把该表依赖的扩展一起恢复；归档里有扩展创建项，也不表示这次选择会执行它。

看失败 SQL，确认缺的是哪一层

保留报错对应的 SQL 和目录项。CREATE TABLE 引用的类型不存在，与表已经建好、COPY 触发函数时找不到类型，是两条不同路径。后一种情况即使扩展存在，也可能要核对函数的 schema 和 search_path，不能继续反复安装扩展。

以下只读查询应在实际恢复目标库执行：

SELECT current_database(), current_user;

SELECT e.extname, e.extversion, n.nspname AS extension_schema
FROM pg_extension AS e
JOIN pg_namespace AS n ON n.oid = e.extnamespace
WHERE e.extname = 'hstore';

SELECT n.nspname, t.typname
FROM pg_type AS t
JOIN pg_namespace AS n ON n.oid = t.typnamespace
WHERE t.typname = 'hstore';

将结果与归档 SQL 使用的 schema 对照。扩展装在另一个库，对当前目标库没有作用；类型装在不同 schema，也不能假定所有归档定义或函数都能找到它。

为选中的表先准备明确的依赖

如果源定义使用 public 中的 hstore，目标库确实缺少该扩展，可以在经过确认的空恢复测试库先安装，再恢复表。示例使用 restore_test，主机、账户、数据库和文件名都需要替换：

psql -h db.example.internal -p 5432 -U restore_user -d restore_test \
  -v ON_ERROR_STOP=1 -c 'CREATE EXTENSION hstore WITH SCHEMA public;'

pg_restore -h db.example.internal -p 5432 -U restore_user \
  -d restore_test --schema=public --table=people \
  --exit-on-error backup.dump

这会在目标库创建扩展，然后恢复归档中的表与相应数据。只用于已确认的测试目标，认证沿用现有受控方式；不要为了照抄示例删除业务库。

服务器需要提供该扩展的安装文件，托管平台还可能限制允许安装的扩展。PostgreSQL 18 的 hstore 是 trusted 扩展，可由具有数据库 CREATE 权限的角色安装，但仍需核对实际版本与平台限制。创建失败时，按明确的安装或权限错误处理，不直接给应用账户扩大管理权限。

若 hstore 已安装，先确认它的 schema、版本和现有对象，不能用删除重建来处理一条类型报错。也不要把扩展装进 template1 当作单次恢复的补丁；那会影响以后创建的数据库。

-t 不等于恢复这张表的全部关联对象

pg_restore -t 的选择规则与 pg_dump -t 不完全相同。恢复时的表参数不支持把 schema 和通配匹配当成同一种写法，schema 可另用 -n 指定；它也不会自动包含所选表的索引等附属对象，更不会递归补齐所有依赖。

除了扩展，还应核对所选表需要的 schema、其他类型、函数和业务依赖。需要精确控制恢复范围时，可用 pg_restore --list 查看目录，复核后通过 --use-list 选择实际需要的项；不能仅根据表名列表推断恢复范围完整。

修正后在空测试目标重新验证，检查建表、数据、索引、约束以及业务查询。此前失败的恢复可能已经创建其他对象或导入部分数据，不应直接把同一份归档重复恢复到那个目标上。

若错误改为 must be owner of extension 且 SQL 是 COMMENT ON EXTENSION，应按扩展注释的所有权检查另行判断。缺少建表依赖与注释权限拒绝，不能都当成可以忽略的恢复警告。