oracle 语法兼容性,Postgres兼容Oracle语法研究-extension

一、背景

在异构数据库迁移到postgres的过程中，会遇到困难主要集中在：

1、旧数据迁移

2、旧应用系统的平滑过渡。

而数据迁移和应用迁移过程中，集中体现在数据库兼容性方面。虽然postgres支持目前主流数据库的大部分数据类型及相关特性，但是在SQL语法上和主流的商业数据库存在一定的差异，造成迁移数据和应用系统时，改造量过大，迁移成本较高，同时难以保证稳定性。

本文主要分析postgres的查询执行过程，提供拓展语法特性的相关思路，降低异构数据库迁移到postgres的成本。

二、兼容性extension设计

1.查询执行过程

查询执行过程

当postgresql的后台服务进程postgres收到前台发来的查询语句后，首先将其传递到查询分析模块，进行词法分析，语法分析和语义分析。若是功能性命令(例如create table,create user和backup命令等)则将其分配到功能性命令处理模块；

对于查询处理命令(SELECT/INSERT/DELETE/UPDATE)则为其构建查询语法树，交给查询重写模块。

查询重写模块对其进行语义分析，生成查询树，交给执行计划模块。

执行计划模块对查询进行查询评估和优化，生成查询执行计划，交给查询执行模块。

查询执行模块根据查询执行计划执行查询。

总的来说流程如下：

SQL命令 --(词法和语法分析)--> 分析树 --(语义分析)--> 查询树 --(生成查询计划)--> 查询计划 --(执行查询计划)-->返回查询结果

在代码里的调用路径如下(方框内为函数，数字显示了调用顺序)：

查询执行过程

语义分析过程：

语义分析

2.兼容性extension设计

根据查询执行过程分析可以看出，SQL进入查询流程时，首先对其进行词法和语法分析，不符合语法规则的SQL，直接报错，不会再执行到后面的流程中，所有，如果要做语法性兼容，首先要在语法分析模块之前，对其进行兼容性改造。改造方案有两个：

方案1

改造思路：在词法分析函数pg_parse_query()中，把调用语法分析raw_parse函数改为if else分支，增加hook指针判断。

执行流程改造图

修改后的查询执行过程

方案2

改造思路：在词法分析函数pg_parse_query()中，把调用语法分析raw_parse函数前加入hook指针判断，如果存在，则调用改写SQL语句。

执行流程改造图

修改后的查询执行过程

方案对比

方案1：实现了一个完整的语法分析，同时兼容postgres和oracle(或其他数据库)，改造基于postgres的语法分析器实现。

方案2：实现了一个差异化的语法分析，区别postgres和oracle(或其他数据库)语法不同点，分析后需要改写原来的SQL语句。

四、注意问题

此extension的语法兼容性改造，只适合作为语法兼容，不适合做语义兼容。

例如一个无参函数：

/* 语句1：标准的SQL写法*/

select func() from t;

/* 语句2：oracle 支持省去无参函数后面的括号 */

select func from t;

对于语句1，语法分析过程可以将func判断为函数。

对于语句2，语法分析过程中，无法知道func属于语法、函数或者其他对象，只有在语义分析过程，通过查阅数据库字典表对象，才能区分。