大家好，去年5月份开始到今年2月份，我们一共割接了40多套PG，今天就来聊一聊遇到的那些迁移和使用的“坑”。
希望这是一期不错的节目。
坑主驾到（一）
开发用to_date()的一定要注意，有可能查询不出数据，wrongresult
查询结果不一致。Oracle能查出数据，PG查出来数据为空。先来看看具体的截图：
其实这原本是一个上百行的SQL，问题发生在此处定位需要不停的拆分和测试，我略微精简了一下。我们调整后的SQL如下。
会发现数据立马有了。
其实这个问题很简单，Oracle使用的date类型是带时分秒的，而Postgresql的date类型是不带时分秒的。所以在Oracle迁移到PostgreSQL，转换的时候都会把Date类型改造成Timestamp类型。
问题就在于PostgreSQL自带了to_date函数。该函数的返回类型是PostgreSQL中的Date类型。
所以在上面就相当于数据类型不一致，导致查不到数据。该问题解决办法有两种：
把to_date函数改造成to_timestamp。 安装第三方插件orafce或者是亚马逊的aws_oracle_ext，使用第三方插件的to_date函数。
坑主驾到（二）
序列顺序问题
这个问题是我们创建了序列，开发使用的时候发现序列产生的值居然比当前序列最大值还要小。
这个问题的主要原因就是Oracle和PostgreSQL在序列上有差异，我们主要来观察一下PG的行为：
1、先创建一个序列，起使值100，cache值20，会话A读一下nextval。
2、接下类在开会话B，读一下nextval，发现值变成了120。
注意按照Oracle数据库的逻辑，此时序列的最大值已经是120了。
3、返回到会话A，再次获取nextval，发现值是101。
此时就出现了开发遇到的情况：序列产生的值居然比当前序列最大值还要小。
大多数序列只要不存在时间依赖关系，使用上都没问题。但是如果出现了数字小的序列一定要比数字大的序列时间早这种逻辑，就需要把序列的cache值设置成1。
坑主驾到（三）
substr函数结果不一致
PostgreSQL
Oracle
Substr函数的起使位置要从1开始，如果位置从0开始，虽然有数据但是和Oracle不一致。
坑主驾到（四）
事务问题
这个问题我对Oracle、MySQL、PostgreSQL做了详尽的测试，结论就是
在Oracle和MySQL中，当其他会话更新或删除了选定的行时，当前会话在执行事务之前将重新检查最新的数据。PostgreSQL当选定的行被其他会话更新或删除时，当前会话将忽略这些行。
事务问题会导致出现数据删除丢失。需要应用程序侧考虑这个问题进行改造。
由于篇幅的原因，今天的“入坑到出坑”娱乐节目，暂时介绍到这里。文中如有错误，请大神们帮忙把“坑”填了。
