客户问: pgpool-II3.1 的log 里面，为何会有Unable to parse 的信息？
但是相关的SQL文却正确执行了的。
为了探究原因，对代码进行了分析。
首先最重要的是：pgpool-II对SQL文的分析，并没有什么特别的意义。
它对自己不能解析的SQL文，都要报这个信息。但是pgpool-II不能解析，并不代表数据库端就不能识别。
说到这里，得说一下：pgpool-II里面对log信息/debug信息的安排比较随意，不是很严谨。
如果我们用 PPAS版里自带的 pgpool-II， 和PPAS数据库打交道的话，就会发现：
很多从Oracle数据库移植过来的SQL文，可以被PPAS识别。却不能被pgpool-II识别。
比如：delete table ，这个在Oracle 看来是正常的。
但是 在 pgpool-II 看来却不行，只有 delete from table 才是它所能够认识的。
无论怎么说，在正式的生产环境里，看到类似 "Unable to Parse" 之类的信息，总是令人十分烦恼的。
pgpool-II的开发者，是否根本没有意思到这一点呢。把它作为debug 而不是log信息，才是更加合理的作法。
从更大的角度来说，并不是软件一开放源代码就万事大吉了。之后还有很多细致的工作需要做。
为了解决这个问题，可以有一个办法：
再额外安装一个纯开放源代码的postgresql(相对 PPAS: Postgres Plus Advanced Server)，
执行出现问题的sql文，postgresql 会报告具体的错误。
比如 ：
delete 里面没有 from
子查询的括号后面没有别名 之类。
按照postgresql 给的提示，修正sql文，再到pgpool-II上去验证，基本可以不再出现 "Unable to Parse"