schema-exploration

探索 PostgreSQL 数据库

从用户的问题入手，除非用户明确要求全面审计数据库，否则不要进行此类审计。使用当前可用的数据库连接；如果没有连接，请请求访问权限，或基于用户提供的架构文件开展工作。仅限于用户授权的数据库和架构。目录元数据可能会暴露敏感名称或源代码：不要在非必要时导出。

工作流

1. 确认当前数据库、服务器版本、角色和范围。使用 overview 进行小范围盘点。选择相关架构；不要假定应用数据位于 public 中。
2. 选出最有希望的对象，并且只阅读对应的深入参考：tables、partitioning/inheritance、foreign tables、views、routines、triggers、security/RLS 或 extensions。仅在问题需要时才查看交叉引用。
3. 通过注释、定义、键和已知依赖关系核实对象含义。名称只是线索，并不能证明业务含义。如果数据派生值有助于分析，请仅在获得针对具体列和访问方式的批准后使用 data-derived values。语义仍有歧义时，请询问用户。
4. 如果用户需要 SQL，请遵循 query authoring：先确定连接键和粒度，然后在获得授权的情况下，使用普通 EXPLAIN 验证经过审查的只读查询。不要把有效的执行计划误当作业务语义的证明。
5. 能够回答后就停止。报告具体的、带架构限定的对象和证据，区分观察结果与推断，并说明限制（权限、统计信息过时、依赖关系缺失、应用逻辑未知）。

发现示例

仅供说明；报告在目标数据库中核实过的事实：

• 观察结果： sales.orders 的主键为 order_id，且 account_id 通过外键指向 sales.accounts.account_id。
• 推断： sales.orders 可能每个订单对应一行；键支持这一推断，但不能确定业务所说的“订单”具体指什么。
• 未解决： 目录中看不出已取消的订单是否仍保留在此表中。假定它们会保留之前，请向应用负责人确认。

安全与执行

• 优先查询结构性目录；pg_stats 源自数据，也需要获得批准。未经授权，不要更改架构、数据、角色或会话级设置。绝不要调用发现的函数或过程、刷新物化视图，或对未知查询运行 EXPLAIN ANALYZE。标记为 STABLE 或 IMMUTABLE 的函数并不意味着安全。
• 如果客户端支持事务，探索时请使用只读事务，并设置合理的语句超时。元数据查询并不意味着可以执行全表计数或不受限制的扫描。采样数据前请先询问；只有在必要时才采样，并明确限制，同时充分了解表大小和访问控制。
• 所有参考查询都是普通 PostgreSQL SQL。使用客户端 API 将 $1、$2 等绑定为值。psql 用户可以参考可选的 psql adapter。绝不要将不可信对象名称直接插入 SQL；在数据查询中，占位符不能替代 SQL 标识符。
• 查询面向 PostgreSQL 18。每个受版本影响的部分都会在适用时注明较旧主版本的替代方案。请先检查 server_version_num。如果查询因权限或版本差异而失败，请报告限制，不要猜测。