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
了。
未完待續…