postgresql原生不支持跨库视图，必须先用postgres_fdw创建外部表再建视图；因其不支持other_db.public.users语法，硬写dblink会导致查询不可预测、事务失效、权限断裂、explain失真及pg_dump丢失逻辑。
不能直接跨库建视图，必须先用 postgres_fdw 创建外部表，再基于外部表建视图——这是唯一安全、可维护的路径。
为什么不能直接 CREATE VIEW 跨数据库查询？
PostgreSQL 原生不支持 SELECT * FROM other_db.public.users 这类语法。视图定义里若硬写跨库连接（比如用 dblink 函数拼接），会导致：查询不可预测、事务隔离失效、权限链断裂、EXPLAIN 看不到真实执行计划。更麻烦的是，这类写法无法被 pg_dump 正确导出，迁移或备份时会静默丢失逻辑。
正确流程：先建 postgres_fdw 外部表，再封装为视图
这是 PostgreSQL 官方推荐的跨库访问方式，也是唯一能保证类型安全、权限隔离和查询下推的方案：
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 在当前数据库执行
CREATE EXTENSION IF NOT EXISTS postgres_fdw; - 创建外部服务器时，
OPTIONS中必须明确指定host、port、dbname，缺一不可；dbname是远程库名，不是本地库名 - 用户映射建议用
CURRENT_USER，避免硬编码密码；若需共享，用PUBLIC映射但必须配合强密码策略 - 创建外部表时，字段类型必须与远程表严格一致；PostgreSQL 9.5+ 可用
IMPORT FOREIGN SCHEMA自动同步结构，但要注意远程 schema 权限是否开放 - 外部表建好后，再用
CREATE VIEW v_remote_users AS SELECT id, username, email FROM foreign_users;封装——此时视图才真正“简化访问”
视图层该做什么、不该做什么？
视图不是万能胶，它只负责抽象和过滤，不能承担跨库协调职责：
- ✅ 应做：剔除敏感列（如
password_hash）、重命名字段（如把remote_id改成user_id）、加固定WHERE过滤（如status = 'active'） - ❌ 避免：在视图里写
JOIN本地表 + 外部表——这会让优化器难以下推条件，可能全量拉取远程数据再本地关联 - ❌ 避免：视图中包含聚合（
GROUP BY）或窗口函数——除非你确认远程表已建好对应索引，否则性能风险极高 - ⚠️ 注意：
WITH CHECK OPTION对外部表无效，别白费力气加
权限和刷新问题最容易被忽略
跨库视图的权限不是“设一次就完事”。常见断点有：
- 远程库的
publicschema 必须对远程用户授予USAGE，否则IMPORT FOREIGN SCHEMA会失败 - 本地用户即使有视图
SELECT权限，若没被授予远程 schema 的USAGE，仍会报permission denied for schema public - 远程表结构变更后，外部表不会自动更新——必须手动
DROP FOREIGN TABLE再重建，或重新IMPORT；视图本身不会报错，但查出来字段错位或 NULL 值 - 如果远程库启用了行级安全策略（RLS），它会生效；但本地视图无法覆盖或绕过它
