kimi-for-coding 在「Oracle到PostgreSQL递归语法转换」的评测结果

这是该 AI 模型在此测试用例上的详细评测结果。

基本信息

  • 模型名称：kimi-for-coding
  • 用例名称：Oracle到PostgreSQL递归语法转换
  • 测试类型：文本生成
  • 评测维度：SQL 专家

系统提示词（System Prompt）

这是给 AI 模型的背景设定和角色指令：

你是一名资深数据库工程师，精通Oracle和PostgreSQL两种数据库的SQL语法差异。 回答要求： 1. 给出完整的转换后SQL语句 2. 简要说明关键语法的对应关系 3. 确保转换后的SQL语法正确，可直接在PostgreSQL中执行

用户提示词（User Prompt）

这是用户给 AI 模型的具体任务要求：

请将以下Oracle递归查询转换为PostgreSQL的WITH RECURSIVE语法： ```sql SELECT employee_id, manager_id, name, LEVEL FROM employees START WITH manager_id IS NULL CONNECT BY PRIOR employee_id = manager_id; ``` 该查询的含义是：从根节点（没有上级的员工）出发，递归遍历整棵员工层级树，并返回每个节点的层级深度。 请给出等价的PostgreSQL写法，并说明主要语法对应关系。

任务要求

AI 模型需要满足以下要求：

  1. 正确使用WITH RECURSIVE定义递归CTE结构
  2. 正确设置递归初始条件（对应START WITH manager_id IS NULL）
  3. 正确编写递归关联条件（对应CONNECT BY PRIOR employee_id = manager_id）
  4. 正确实现LEVEL列的等价计算（使用depth或level字段递增）
  5. 说明Oracle与PostgreSQL关键语法的对应关系

评测结果

综合得分

该模型在此用例的得分为：95.3 分（满分 100 分），已通过

基础难度评测结果

  • 得分：95.3 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

**转换后的 PostgreSQL 语句：** ```sql WITH RECURSIVE employee_tree AS ( -- 根节点查询（对应 Oracle 的 START WITH） SELECT employee_id, manager_id, name, 1 AS level FROM employees WHERE manager_id IS NULL UNION ALL -- 递归查询（对应 Oracle 的 CONNECT BY） SELECT e.employee_id, e.manager_id, e.name, et.level + 1 AS level FROM employees e INNER JOIN employee_tree et ON e.manager_id = et.employee_id ) SELECT employee_id, manager_id, name, level FROM employee_tree; ``` --- **关键语法对应关系：** | Oracle 语法 | PostgreSQL 对应 | 说明 | | :--- | :--- | :--- | | `START WITH manager_id IS NULL` | `WITH RECURSIVE` 的**初始查询**（非递归部分）`WHERE manager_id IS NULL` | 定义递归的起始锚点（根节点） | | `CONNECT BY PRIOR employee_id = manager_id` | `UNION ALL` 后的**递归查询** `JOIN employee_tree ON e.manager_id = et.employee_id` | 递归连接条件：`employee_tree` 中的当前行（父节点）与 `employees` 表中的子节点关联 | | `PRIOR employee_id` | `et.employee_id` | `PRIOR` 在 Oracle 中表示父级（上一层）的行，在 PostgreSQL 中通过递归 CTE 的别名 `et` 引用 | | `LEVEL`（伪列） | 显式定义 `1 AS level` 并在递归中 `et.level + 1` | PostgreSQL 没有 `LEVEL` 伪列，需手动计算层级深度，根节点从 1 开始 | | 整体查询 | `WITH RECURSIVE ... SELECT ... FROM employee_tree` | 最终从递归 CTE 中查询结果，无需再使用 `FROM employees` | > **注意**：如果原 Oracle 查询使用了 `ORDER SIBLINGS BY` 来控制同级排序，在 PostgreSQL 中需要在最终 `SELECT` 后添加 `ORDER BY level, ...` 来实现类似效果。上述转换未包含排序，因此保持最简等价形式。

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】候选输出整体质量优秀，SQL转换语法正确、语义等价，对应关系说明清晰准确。核心转换要素（WITH RECURSIVE结构、锚点查询、递归JOIN条件、LEVEL列模拟）均已正确实现，可直接用于生产环境。与参考答案相比，缺少执行流程的逐步说明和循环引用防护等进阶内容，但对于「basic」难度级别的测试题而言，候选输出已完全满足要求，整体表现接近满分水平。 【GEMINI】模型表现出色，完美完成了 Oracle 到 PostgreSQL 递归查询的转换任务。SQL 代码质量高，逻辑清晰，对应关系的解释准确到位，是一份高质量的参考答案。 【KIMI】该候选输出是一次高质量的Oracle到PostgreSQL递归查询转换。SQL语法正确、语义等价，说明清晰有条理。主要亮点包括：正确使用WITH RECURSIVE结构、准确转换START WITH和CONNECT BY条件、合理模拟LEVEL伪列、以及提供了清晰的语法对照表。 minor改进空间包括：增加对递归终止机制的说明、补充PRIOR关键字的灵活性解释、以及考虑添加ORDER BY优化结果展示。整体而言，该输出完全满足题目要求，可直接用于生产环境。

进阶难度评测结果

  • 得分：95.6 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

以下是等价的 **PostgreSQL** 完整可执行 SQL（假设表已存在）： ```sql WITH RECURSIVE tree AS ( -- 锚点成员（Anchor Member）：对应 Oracle START WITH SELECT employee_id, name, manager_id, 1 AS level, '/' || name AS full_path, name AS root_name, ARRAY[employee_id] AS path_ids, -- 用于 NOCYCLE 循环检测 ARRAY[name] AS sort_path -- 用于 ORDER SIBLINGS BY FROM employees WHERE manager_id IS NULL UNION ALL -- 递归成员（Recursive Member）：对应 Oracle CONNECT BY SELECT e.employee_id, e.name, e.manager_id, t.level + 1, t.full_path || '/' || e.name, t.root_name, t.path_ids || e.employee_id, t.sort_path || e.name FROM employees e INNER JOIN tree t ON e.manager_id = t.employee_id WHERE t.level **提示**：如果业务上需要保留“根节点为第 1 层”的语义，锚点中固定 `1 AS level`，递归中使用 `t.level + 1`，并限制 `t.level < 3` 即可精确对应 Oracle 的 `LEVEL <= 3`。

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】候选输出质量极高，完整覆盖了所有要求的转换点，SQL语法正确可执行，各Oracle特性的等价实现方案选择合理（均采用了与参考答案一致的最优方案），说明详尽清晰且有深度。与参考答案相比，在结构组织上略有差异（参考答案将说明放在SQL后面作为独立章节，候选输出将说明紧跟SQL后以分节形式呈现），但内容质量相当。整体而言是一份接近满分的优秀回答。 【GEMINI】这是一份非常专业的 SQL 迁移指南。模型不仅给出了正确、高效的 PostgreSQL 代码，还深入解释了背后的实现原理（如数组字典序如何模拟树形排序），并考虑到了性能优化（递归剪枝）。完全符合资深数据库工程师的专业水准，无任何明显瑕疵。 【KIMI】候选输出是一份高质量的Oracle到PostgreSQL递归查询转换方案，SQL语法正确、语义等价、说明清晰。与参考答案相比，核心实现思路高度一致（均采用数组追踪NOCYCLE、数组路径模拟ORDER SIBLINGS BY、字符串拼接模拟SYS_CONNECT_BY_PATH、根节点值透传、递归条件提前剪枝），仅在细节呈现上略有差异：候选输出更强调'推荐方案vs不推荐方案'的对比说明，参考答案则更侧重'双重保险'的防御性编程和全局汇总。整体达到专业数据库工程师的迁移方案水准。

困难难度评测结果

  • 得分：88.1 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

以下是将该 Oracle 递归层级查询转换为 **PostgreSQL `WITH RECURSIVE`** 的完整等价实现。该方案覆盖了所有 Oracle 特有语法（`LEVEL`、`SYS_CONNECT_BY_PATH`、`CONNECT_BY_ROOT`、`CONNECT_BY_ISLEAF`、`PRIOR`、`START WITH ... CONNECT BY`、`ORDER SIBLINGS BY`、`MINUS`、`NOCYCLE`），并针对行为差异和性能边界做了详细说明。 --- ### 1. 完整的 PostgreSQL 等价 SQL ```sql WITH RECURSIVE root_employees AS ( /* 任务2：Oracle MINUS 的等价实现 找出「作为他人的上级，且自身没有上级」的顶级根节点。 PostgreSQL 使用 EXCEPT（默认去重），语义与 Oracle MINUS 完全一致。 */ SELECT manager_id AS employee_id FROM employees WHERE manager_id IS NOT NULL EXCEPT SELECT employee_id FROM employees WHERE manager_id IS NOT NULL ), hierarchy AS ( -- Anchor Member：递归起点，对应 Oracle START WITH（LEVEL = 1） SELECT e.employee_id, e.name, e.department_id, d.dept_name, e.employee_id AS root_id, -- CONNECT_BY_ROOT employee_id 1 AS level, -- Oracle LEVEL 伪列（从 1 开始） e.name AS full_path, -- SYS_CONNECT_BY_PATH(name, ' > ') NULL::VARCHAR AS parent_name, -- PRIOR e.name（根节点无父节点） ARRAY[e.employee_id] AS emp_path, -- 用于 NOCYCLE 循环检测（传递节点路径） -- 任务5：ORDER SIBLINGS BY 的排序路径编码 -- 将 (name ASC, employee_id DESC) 编码为数组，逐层追加。 -- employee_id DESC 的实现：使用 BIGINT 最大补数的零填充字符串，使字典序等价于数值降序。 ARRAY[ e.name, lpad((9223372036854775807::bigint - e.employee_id::bigint)::TEXT, 19, '0') ] AS sort_path FROM employees e JOIN departments d ON e.department_id = d.department_id WHERE d.is_active = 1 -- 原 WHERE 过滤（在递归前生效） AND e.employee_id IN (SELECT employee_id FROM root_employees) UNION ALL -- Recursive Member：递归下探（LEVEL = LEVEL + 1） SELECT e.employee_id, e.name, e.department_id, d.dept_name, h.root_id, -- CONNECT_BY_ROOT 保持传递 h.level + 1, h.full_path || ' > ' || e.name, -- 路径拼接 h.name AS parent_name, -- 父节点（即上一层递归行）的 name h.emp_path || e.employee_id, h.sort_path || ARRAY[ e.name, lpad((9223372036854775807::bigint - e.employee_id::bigint)::TEXT, 19, '0') ] FROM hierarchy h JOIN employees e ON e.manager_id = h.employee_id JOIN departments d ON e.department_id = d.department_id WHERE d.is_active = 1 -- 任务4：LEVEL 过滤的正确处理 -- 最终只需要 LEVEL 1GB）可能有限制 |...

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】候选输出是一份高质量的Oracle到PostgreSQL递归查询迁移答案，覆盖了所有要求的转换点，SQL结构完整可执行，六个任务均有条理清晰的说明。特别亮点：CONNECT_BY_ISLEAF的EXISTS实现考虑了d.is_active=1过滤条件，语义上比参考答案更贴近Oracle原始行为；行为差异分析全面，提及了PostgreSQL 14+的新语法。主要不足：sort_path数组中name字段未使用LPAD固定宽度，多字节字符场景下排序可能不准确；SYS_CONNECT_BY_PATH的首字符格式差异在SQL层面未修正也未在差异表中单独说明。整体而言，这是一份接近满分的优秀回答，实用性和分析深度均很高。 【GEMINI】该回答表现极其出色，展现了深厚且专业的数据库迁移实战经验。提供的 PostgreSQL SQL 语句不仅语法完全正确，而且在逻辑结构上高度优化。 在语义等价性方面，模型精准捕捉到了 Oracle 递归查询的诸多细微特性。特别是在处理 `CONNECT_BY_ISLEAF` 时，模型敏锐地指出该伪列在 Oracle 中受 `WHERE` 条件过滤的影响，并给出了语义最严谨的 `EXISTS` 子查询实现，这优于常规的简单表关联方案。对于 `ORDER SIBLINGS BY` 的多列排序需求，利用数组结合‘数值补数’的技巧（将 ID 降序转为字符串升序）解决了 PostgreSQL 数组排序仅支持升序的局限，非常精妙。 在深度分析维度，模型对 `LEVEL` 过滤位置的‘递归内剪枝 + 递归外过滤’策略解释得非常透彻，既兼顾了性能又保证了结果集的正确性。最后的差异分析表详尽列举了循环检测、路径格式、叶子节点语义及性能索引建议，为实际迁移工作提供了极具价值的参考。整体回答逻辑严密，完全符合高级数据库工程师的标准。 【KIMI】该候选输出在结构完整性上表现较好，覆盖了所有要求的转换点，但在核心语义等价性上存在关键缺陷：将部门过滤条件错误地前置到递归CTE的锚点成员中，违背了Oracle CONNECT BY先于JOIN/WHERE的执行顺序，这是层级查询迁移中的典型陷阱。CONNECT_BY_ISLEAF的实现虽然采用了EXISTS子查询，但由于递归展开范围已被部门过滤缩小，其语义与Oracle不等价。ORDER SIBLINGS BY的sort_path方案设计巧妙但存在name字段字典序假设风险。整体而言，该输出适合作为初稿，但需要修正递归CTE的过滤位置才能用于生产环境。

相关链接

您可以通过以下链接查看更多相关内容：

加载中...
100%