wp-knowledge 0.12.1

# PostgreSQL Provider 后续任务

中文 | [English](../../en/tasks/postgres-provider.md)

## 当前基线

已经具备：

- `[provider] kind = "postgres"` 基础接入
- `query_fields(...)` / `cache_query_fields(...)` 作为推荐入口
- 基础查询、命名参数重写和手工验证脚本

还不算“长期稳定可运营”的 PostgreSQL 支持。

## 剩余任务

### 1. 连接池

- 现状：`src/postgres.rs` 仍以单连接串行查询为主
- 目标：
  - 接入连接池
  - 定义连接失败、断开和重试行为
  - 让并发查询不再依赖单连接串行执行

### 2. 初始化自检

- 现状：初始化阶段主要只验证“能不能连上”
- 目标：
  - 启动时检查库、schema、权限和关键对象
  - 在初始化阶段直接暴露错库、错权限、错 schema

### 3. SQL / UDF 能力边界

- 现状：基础 SQL 可用，但 SQLite UDF 体系没有完整迁移
- 目标：
  - 明确哪些 SQL 可直接迁移
  - 明确哪些 SQL 需要改写
  - 明确哪些函数需要用户自行在 PostgreSQL 中提供

### 4. 类型覆盖

- 现状：返回列类型和参数绑定仍不完整
- 目标：
  - 补齐常用数值、时间、JSON、网络类型
  - 对不支持类型给出清晰错误

### 5. 自动化验证

- 现状：仍偏手工验证
- 目标：
  - 补齐 CI 验证路径
  - 在 Compose / `testcontainers` 中选定一种主路径
  - 失败时输出足够的连接与 SQL 诊断信息

### 6. 消费侧端到端示例

- 现状：`wp-knowledge` 内可测，消费侧链路不完整
- 目标：
  - 在消费仓库补 PostgreSQL 示例
  - 用真实 schema 跑通 `wp-oml`
  - 给出可复用的运行说明

### 7. 兼容接口收尾

- 现状：`query_named(...)` / `cache_query(...)` 仍在兼容旧 SQLite 风格
- 目标：
  - 新代码默认走 provider-neutral API
  - 明确兼容接口的保留范围和弃用策略

## 建议顺序

1. 连接池
2. 初始化自检
3. SQL / UDF 边界
4. 类型覆盖
5. 自动化验证
6. 端到端示例
7. 兼容接口收尾