为什么没有像样的sql解析器？

Question

我目前正在做一些oracle sql分析，经常遇到各种sql解析器无法正确解析的有效sql语句。要么他们无法解析它，要么他们生成的抽象语法树不知何故搞乱了。似乎唯一能够真正处理oracle sql的解析器是他们自己的解析器，该解析器不是公开可用的，也不能作为独立解析器获得。

我知道有不同的sql语法，遵守所有的语法可能是不可能的。但是，即使是声称是Oracle SQL解析器的解析器也不是在所有情况下都能成功。

您认为通常难以实现sql解析器或特别是oracle sql解析器的主要原因是什么？

最好的，威尔

Answer 1

好的解析器很难写。这从解析器代码的代码生成器开始(它通常使用一些(E)类似BNF的语法，这有其自身的局限性)。

解析器中的错误处理本身就是一个研究课题。这不仅是关于检测错误，而且还提供了有用的信息，哪些可能是错误的以及如何解决它。一些解析器甚至不提供位置信息(“错误发生在行/列”)。

接下来是SQL，它的意思是“结构化查询语言”，而不是“标准查询语言”。有一个SQL标准，甚至有几个，但您找不到一个实现其中任何一个的数据库。

甲骨文不情愿地提供了VARCHAR，但您最好使用VARCHAR2。一些数据库提供递归/树状查询。它们都使用自己的特殊语法来实现此目的。连接在标准(join，left join，...)中定义得非常清楚。但是，如果可以使用+，为什么还要麻烦呢？

最重要的是，对于每个数据库版本，都会在语法中添加新的功能。

因此，虽然您可以编写一个可以读取标准用例的解析器，但是编写一个能够支持全球所有数据库提供的所有功能的解析器几乎是不可能的。我甚至不是在谈论这些解析器中可能遇到的bug。

一种解决方案是如果所有数据库供应商都发布语法文件。但这些都是皇冠上的明珠(IP)。因此，您应该感到高兴的是，您可以使用它们，而不必为每个解析的字符*CPU数量支付许可费。

Answer 2

当一个制造商声称支持一种语言X时，他指的是“类似于X标准的东西”，而不是标准。由于历史原因，制造商在标准成为标准之前实现了语言X，因此他们一开始就走错了路；试图使他们的版本与标准匹配通常会破坏他们庞大的用户代码库；他们总是想要添加自己的好东西来锁定他们的用户。

这适用于SQL、C、C++……据我所知，人们真正努力匹配标准的唯一语言是Ada，甚至它也有多种方言。(看看浏览器接受了什么！)

所以你不能指望一个现成的通用SQL解析器来解析PLSQL。你真的需要一个PLSQL解析器。这些都很难构建，因为文档很差，Oracle没有理由去修复它，当然也没有动力去帮助语法构建器。

我的公司(语义设计)有一个涵盖10g的PLSQL parser (甲骨文的文档是poor...we，不断从参考文档中寻找变体)，并且完成了11g的大部分工作。我们已经在数百万行PLSQL代码中运行了它。

Answer 3

他们做错了？:)...这显然可以做到，因为数据库引擎中的解析器工作得很好;)...这可能是由于几个因素造成的。该方言可能没有很好的文档记录，或者可能最近对该方言的更改没有在所讨论的解析器中实现。