1. 不同數據類型比較
先來看一段SQL。表dean_test中字段a的類型是整型INT，字段b的類型是字符串/字符型STRING/VARCHAR。
select * from dean_test where a = b
這就是不同數據類型比較。
現實中發現不少數據類型不匹配的比較能兼容地進行隱性類型轉換。但是，隱性類型轉換的一個大前提應該是不能丟失精度！換句話說，顯性轉換和隱性轉換的結果必須是一致的！
2. hive的坑
date和string
hive早期的版本是沒有date類型的，所以date都是用string來表示。因此早期的date_add返回的數據類型是string。
我們舉個例子：下面這個條件在以前以字符串進行比較的時候是不會有問題的。結果應該是true。
'2019-07-11 08:00:00' > date_add('2019-07-12', -1)
它等價於
'2019-07-11 08:00:00' > '2019-07-11'
但是現在date_add函數返回的數據類型是date。於是date > string在進行隱性轉換的時候，按之前官方說法是date會轉成string，那麼上面的條件是能成立的，應該是true。
然而如今hive代碼中的情況是，string被轉成了date。因此'2019-07-11 08:00:00'在被轉換成date的時候，丟失了時間精度。於是上面的條件就等價於
'2019-07-11' > '2019-07-11'
所以這個不等式在新版的hive中是不成立的，結果是false。
而我們在date_add('2019-07-12', -1)外面再包一層強制類型轉換
'2019-07-11 08:00:00' > cast(date_add('2019-07-12', -1) as string)
這個結果就是true了。
未完待續…