PostgreSQL 的自省功能比较复杂（来自构建原生客户端的经验教训）
我正在构建 Tabularis，一个原生数据库客户端（Rust + Tauri）。
MySQL 的支持已经相当不错，但 PostgreSQL 的实现要困难得多——这并不是因为性能问题，而是因为 <i>自省</i>。
Postgres “可以工作”，但一旦超出基本的表和列，事情就会迅速变得复杂。
到目前为止，我遇到的一些问题包括：
- 类型系统：
数组、JSON/JSONB、域、自定义类型、范围、几何类型——大多数客户端要么将它们扁平化为文本，要么处理不一致。
- 模式自省：
information_schema 的功能有限。
pg_catalog 功能强大但微妙。
触发器、函数、分区表、继承、物化视图都需要特殊处理。
- PostgreSQL 特有的用户体验：
CTE 重的查询、EXPLAIN ANALYZE 输出、PostGIS / pgvector 等扩展——这些无法干净地映射到通用的数据库抽象。
我目前使用 SQLx 和信息模式 + pg_catalog 查询的组合，但我相信还有更好的模式我尚未发现。
我希望能得到以下人的反馈：
- 编写过复杂 PostgreSQL 自省查询的人
- 对 PostgreSQL 客户端应该如何表示模式和类型有看法的人
- 对现有 PostgreSQL 图形用户界面感到沮丧的人
代码库（Apache 2.0）：https://github.com/debba/tabularis
我乐于学习、迭代，并修正错误的假设。
查看原文
I’m building Tabularis, a native database client (Rust + Tauri).
MySQL support is in a good place, but PostgreSQL has been much harder to get right — not for performance, but for <i>introspection</i>.<p>Postgres “works”, but once you go beyond basic tables and columns, things get tricky fast.<p>Some gaps I’ve hit so far:<p>- Type system:
Arrays, JSON/JSONB, domains, custom types, ranges, geometric types — most clients either flatten them to text or handle them inconsistently.<p>- Schema introspection:
information_schema only goes so far.
pg_catalog is powerful but subtle.
Triggers, functions, partitioned tables, inheritance, materialized views all require special handling.<p>- Postgres-specific UX:
CTE-heavy queries, EXPLAIN ANALYZE output, extensions like PostGIS / pgvector — these don’t map cleanly to generic DB abstractions.<p>I’m currently using SQLx and a mix of information_schema + pg_catalog queries, but I’m sure there are better patterns I’m missing.<p>I’d love feedback from people who:
- Have written serious Postgres introspection queries
- Have opinions on how Postgres clients <i>should</i> represent schemas and types
- Have been frustrated by existing Postgres GUIs<p>Repo (Apache 2.0): https://github.com/debba/tabularis<p>Happy to learn, iterate, and fix wrong assumptions.