背景现状：Babelfish双端口架构
当前数据库使用Babelfish插件（bbf）来支持SQLServer模式，采用双端口设计：
核心问题
- SQLServer模式的SQL与PG模式SQL语法存在差异
- 逻辑复制是PG内核特有功能，TSQL端口无法识别或创建
- 需要在SQLServer模式下实现逻辑复制功能
两种解决方案对比
| 方案 | 描述 | 端口需求 | 开发量 | 复杂度 |
|---|---|---|---|---|
| 方案一 | 逻辑复制语句走PG端口，DDL/DML走TSQL端口 | 双端口 | 无需开发 | 低 |
| 方案二 | 所有操作都走TSQL端口，适配逻辑复制语句 | 单端口 | 需要开发 | 高 |
方案一：双端口模式（当前推荐）
方案二：单端口模式（需要适配）
关键决策点：选择哪种方案取决于业务需求和技术资源。方案一简单但需要管理两个端口，方案二用户体验更好但开发工作量大。
PostgreSQL逻辑复制语句清单
| 类型 | SQL语句 | TSQL端口支持 |
|---|---|---|
| 发布 | CREATE PUBLICATION |
不支持 |
| 订阅 | CREATE SUBSCRIPTION |
不支持 |
| 修改发布 | ALTER PUBLICATION |
不支持 |
| 修改订阅 | ALTER SUBSCRIPTION |
不支持 |
| 删除发布 | DROP PUBLICATION |
不支持 |
| 删除订阅 | DROP SUBSCRIPTION |
不支持 |
| 复制槽 | pg_create_logical_replication_slot |
不支持 |
| 查看复制 | pg_stat_subscription |
不支持 |
| 查看slot | pg_replication_slots |
不支持 |
若选择单端口方案，上述所有语句都需要适配到SQLServer模式。
DDL自动同步核心流程
DDL同步主要涉及4个核心步骤，与原生PG模式一致，区别主要在第4步（订阅端Apply）。
单端口方案的关键挑战
两种方案的适配工作量对比
| 方案 | DDL捕获 | 写入系统表 | 发送到订阅端 | 订阅端Apply | 总工作量 |
|---|---|---|---|---|---|
| 方案一双端口 | 与PG一致 | 与PG一致 | 与PG一致 | 区分数据库模式即可 | 小 |
| 方案二单端口 | 与PG一致 | 与PG一致 | 与PG一致 | 需实现TSQL上下文+ Babel解析 | 大 |
技术方案决策树
总结与建议
- 当前推荐方案一（双端口）：逻辑复制语句走PG端口，DDL/DML走TSQL端口，开发量小，风险低
- DDL同步核心流程：捕获→写入系统表→发送到订阅端→Apply，与PG模式一致
- 关键差异点：订阅端Apply时需要根据端口来源决定执行方式
- 方案二（单端口）：用户体验更好，但需要大量适配工作，建议作为后续迭代目标
核心问题：如何定义用户的使用方式？
- 方式A：一个端口完成完整逻辑复制功能 → 方案二
- 方式B：两个端口各司其职 → 方案一（推荐）
