PostgreSQL 数据库的结构
我来给你把这个 PostgreSQL 数据库的结构和每个部分的作用讲清楚，按层级拆解👇
一、最上层：db_name（你的数据库名）
这是你当前连接的 PostgreSQL 数据库实例，PostgreSQL 里一个服务下可以有多个独立数据库，xin 就是其中之一，你的所有数据、表、视图等都存在这个数据库里。
二、information_schema（信息模式）
这是一个标准 SQL 定义的系统视图集合，相当于数据库的 "元数据说明书"，用来以标准化方式查询数据库对象信息，不依赖 PostgreSQL 特定语法，跨数据库兼容。
表格
| 子项 | 说明 |
|---|---|
tables |
包含当前数据库中所有表（包括系统表和用户表）的信息，比如表名、所属模式、创建时间等 |
views |
包含所有视图（虚拟表）的定义信息，比如视图名、定义 SQL 语句 |
routines |
包含所有存储过程、函数的信息，比如函数名、参数、返回类型 |
object types |
包含数据库中自定义数据类型的信息 |
核心用途 ：写跨数据库兼容的 SQL 查询时，优先用它来查元数据，比直接查 pg_catalog 更通用。
三、pg_catalog（PostgreSQL 系统目录）
这是 PostgreSQL 自己的核心系统表 / 视图集合，相当于数据库的 "操作系统内核"，存储了数据库运行所需的所有元数据、配置和内置对象，是 PostgreSQL 专用的。
表格
| 子项 | 说明 |
|---|---|
tables |
PostgreSQL 内置的系统表（如 pg_class、pg_namespace），是数据库元数据的物理存储载体 |
views |
基于系统表构建的系统视图，方便查询元数据（如 pg_tables、pg_views） |
routines |
PostgreSQL 内置的所有函数、存储过程（比如字符串函数、聚合函数、类型转换函数等），你看到的 3129 个就是系统自带的 |
aggregates |
内置的聚合函数（如 sum()、count()、avg() 等），共 157 个 |
operators |
内置的运算符（如 +、-、=、LIKE 等），以及运算符对应的实现逻辑，共 799 个 |
object types |
PostgreSQL 内置的数据类型（如 int、text、timestamp 等），共 68 个 |
collations |
排序规则（比如中文排序、大小写敏感规则），共 858 个，影响字符串比较和排序 |
operator classes / operator families |
索引操作符类 / 族，定义不同索引（如 B 树、哈希）如何处理运算符，是索引优化的底层逻辑 |
核心用途：PostgreSQL 数据库的核心依赖，系统正常运行离不开它；DBA 排查问题、优化性能时，经常会直接查询这里的系统表。
四、public（默认用户模式）
这是你创建数据库时默认存在的用户模式（Schema），也是绝大多数用户对象的存放地，你的业务表、自定义函数等都在这里。
表格
| 子项 | 说明 |
|---|---|
tables |
你自己创建的业务表（共 31 个），是存储业务数据的核心载体 |
routines |
你自定义的函数、存储过程（共 109 个），用来封装业务逻辑 |
operators |
你自定义的运算符（共 59 个，很少用，一般是高级扩展或自定义类型才会用到） |
sequences |
序列对象（共 28 个），通常用来给表的主键生成自增 ID，比如 SERIAL/IDENTITY 列底层就是用它实现的 |
object types |
你自定义的数据类型（共 5 个），比如枚举类型、复合类型 |
operator classes / operator families |
你自定义的索引操作符类 / 族（共 5 个，一般是用扩展或自定义索引时才会创建） |
核心用途：存放你所有的业务相关数据库对象，是你开发和维护的重点区域。
五、Database Objects（数据库级对象）
这是数据库层面的全局对象，不属于某个特定模式，是整个数据库实例共享的配置和扩展。
表格
| 子项 | 说明 |
|---|---|
access methods |
访问方法（共 7 个），也就是 PostgreSQL 支持的索引类型，比如 B 树、哈希、GIN、GiST 等 |
casts |
类型转换规则（共 229 个），定义不同数据类型之间如何自动 / 手动转换，比如 text 转 int |
extensions |
已安装的扩展（共 3 个），比如 pg_stat_statements（SQL 性能分析）、uuid-ossp（UUID 生成）等，用来给 PostgreSQL 增加额外功能 |
languages |
支持的过程语言（共 4 个），比如 plpgsql（默认存储过程语言）、sql、python、c 等 |
virtual views |
虚拟视图（共 1 个，一般是 IDE 或工具生成的，不是数据库原生对象） |
核心用途：管理数据库的全局配置、扩展和底层能力，DBA 优化和扩展数据库功能时会用到。
💡 补充：几个关键概念的通俗理解
- Schema（模式） ：相当于数据库里的 "文件夹"，用来把表、函数等对象分组管理，
information_schema、pg_catalog、public都是不同的模式。 - 元数据 ：描述数据库对象的数据，比如表名、字段类型、索引定义等，
information_schema和pg_catalog都是元数据的存储 / 查询入口。 - 扩展（extensions） ：PostgreSQL 的插件机制，比如安装
pgvector扩展就能支持向量数据库功能，安装hstore就能支持键值对存储。
关于 CREATE POLICY
CREATE POLICY 是行级安全策略（RLS） ，用来控制哪些用户能查 / 改表里的哪些行，是 PostgreSQL 最常用的权限控制之一。
我用最简单、最实用的方式给你讲清楚👇
一、CREATE POLICY 放在哪里？
1. 必须依附在 表 上
策略不属于数据库、不属于模式，只属于某一张表。
2. 语法位置
sql
-- 标准写法
CREATE POLICY 策略名
ON 表名
FOR 操作 -- SELECT/INSERT/UPDATE/DELETE/ALL
TO 角色/用户 -- 给哪个账号用
USING (条件); -- 行过滤条件3. 它属于哪个模式？
表在哪个 schema，策略就在哪个 schema。比如：
sql
CREATE POLICY p_user_select ON public.user_table ...;这个策略就属于 public 模式下的 user_table 表。
二、最关键：使用前必须先开 RLS
不开行级安全，策略等于白写！
sql
-- 开启表的行级安全
ALTER TABLE 表名 ENABLE ROW LEVEL SECURITY;三、完整示例（直接复制可用）
sql
-- 1. 先开启行级安全
ALTER TABLE user_info ENABLE ROW LEVEL SECURITY;
-- 2. 创建策略：普通用户只能看自己的数据
CREATE POLICY user_see_self
ON user_info
FOR SELECT
TO app_user -- 你的业务用户
USING (user_id = current_setting('app.user_id')::int);四、如何查看已有的 POLICY？
方法 1：查系统表（最准）
sql
SELECT * FROM pg_policies WHERE tablename = '你的表名';方法 2：在工具里看
- DBeaver / Navicat / PGAdmin
- 展开表 → Security → Policies就能看到所有策略。
五、如何修改 POLICY？（重点）
PostgreSQL 没有 ALTER POLICY 修改内容 的语法！修改策略 = 删除旧的 + 创建新的
标准修改流程：
sql
-- 1. 删除旧策略
DROP POLICY IF EXISTS 策略名 ON 表名;
-- 2. 创建新策略（写你改后的逻辑）
CREATE POLICY 策略名
ON 表名
FOR SELECT
TO 角色
USING (新条件);六、如果你只想改策略的权限 / 角色
可以用 ALTER POLICY（只能改角色，不能改过滤条件）
sql
ALTER POLICY 策略名 ON 表名 TO 新角色;七、快速总结（你记这 3 句就够）
- CREATE POLICY 必须写在表上
- 必须先开 ALTER TABLE ... ENABLE ROW LEVEL SECURITY
- 修改策略 = DROP + 重新 CREATE