有一天，一个开发找到我说。他的这个select 任意列 在查出数据的情况下 点击图1的这个按钮，数据逐步加载，然后就会出图2的报错。

                                                              图1

                                                                            图2

我第一感觉，任意列都这样，岂不是要走进科学了？而且神奇的是，不是一开始报错，是数据逐步加载的时候才报错。这一听的确很诡异。也就是这个描述，让我走了一段弯路。不过马上觉得思路不对。

我就想了一下，既然任意列都报错，那么就不是from之前的问题，而是where之后的问题。他的where也很简单：                time有between 范围，然后 and  tpye=65。type是一个列的名字。

我们检查了time列，数据类型是date类型。既然是date类型，数据在写入表的时候已经已经做了校验，就排除这个列的问题了。剩下的就是column=65。尽管看上去没有问题，但是这是唯一的可能性了。

当然最后我是解决了这个问题，我们来复现一下这个问题，同时对比一下其他数据库的情况。

                                                                            图3

表就是id a b 三个列，分别是id是int a和b都是字符串。

当字段是数值型的时候，=右边就是数值。

当字段是字符型的时候，=右边应该是字符，如果是数值的话，就会复现我们今天这个。

结论就是这个表的这个字段是字符串，也就是 上面提到的type=65，如何解决那么就是 type='65'就好了。

之所以会发生数据陆续加载中才会出来，是因为这一列有很多空值，空值不报错，但是遇到有数据的行就把报错了。

那么其他数据库上会如何呢？

我们来看看MySQL的

                                                                         图4

在图4中a是int型，无论怎么写都不出错。（这里我们先不考虑索引，仅仅考虑执行会不会出错）

                                                                         图5

在图5中b是字符型，无论怎么写都不出错。（这里我们先不考虑索引，仅仅考虑执行会不会出错）。

也就是说在Oracle中出错的在MySQL中没有问题。反过来说在MySQL中可以执行，但是到Oracle中就把报错了。

在那么在PG中会是如何？

                                                                    图6

图6在PG中和之前一样的建表。

                                                                                图7

看到图7，发现PG的检查和MySQL不一样，和Oracle是一样的。字符型的列，必须带引号。

以上是Oracle MySQL和PG在这个场景上的差异。