我很驚訝!下面這條語句是有效的SQL SERVER
:SQL Server:非數字字符串+(一元)運算符
SELECT +'ABCDEF'
已SQL Server
定義+
爲Unary
運營商對於字符串類型?
我很驚訝!下面這條語句是有效的SQL SERVER
:SQL Server:非數字字符串+(一元)運算符
SELECT +'ABCDEF'
已SQL Server
定義+
爲Unary
運營商對於字符串類型?
這是我自己回答這個問題(另請參閱在最後更新):
沒有,沒有對字符串表達式定義這種一元運算符。這可能是一個錯誤。
說明:
給出的說法是有效的,它產生以下結果:
(No column name)
----------------
ABCDEF
(1 row(s) affected)
這相當於做SELECT
聲明不使用+
標誌:
SELECT 'ABCDEF'
編譯時不會出現任何錯誤,實際上正在成功執行,給人的印象是+
對給定字符串的操作是Unary
操作。但是,在官方的T-SQL
文件中,沒有提到這樣的操作員。實際上,在標題爲「String Operators」的部分中,+
出現在兩個字符串操作中,分別是+ (String Concatenation)
和+= (String Concatenation)
;但既不是Unary
操作。此外,在標題爲「Unary Operators」的部分中,引入了三個運營商,其中只有一個運營商是+ (Positive)
。但是,對於這個似乎是相關的問題,很快就會清楚,該運算符也與非數字字符串值無關,因爲運算符的解釋明確指出此運算符僅適用於數值: 「Returns the value of a numeric expression (a unary operator)」。
也許,該運營商有成功地接受成功評估爲數字,如已經在這裏所使用的這些字符串值:當執行上面的語句
SELECT +'12345'+1
,它生成一個號碼在它的輸出被評價爲一個數字,加給它的數字小值,這是1
在這裏,但它可能顯然是任何其他款項均定字符串的總和:
(No column name)
----------------
12346
(1 row(s) affected)
不過,我懷疑這解釋是正確的,因爲它提出了以下問題:
首先,如果我們接受這種解釋是正確的,那麼我們可以得出結論,表達式+'12345'
被評估爲數字。如果是這樣,那麼爲什麼這些數字可能出現在字符串相關函數中,如DATALENGTH
,LEN
等你可以看到一條語句,如本:
SELECT DATALENGTH(+'12345')
是相當有效的,它導致以下:
(No column name)
----------------
5
(1 row(s) affected)
這意味着+'12345'
被評價爲一個字符串不是一個數字。這可以如何解釋?
其次,雖然類似的語句與-
運營商,比如這個:
`SELECT -'ABCDE'`
,甚至這樣的:
`SELECT -'12345'`
產生下面的錯誤:
Invalid operator for data type. Operator equals minus, type equals varchar.
爲什麼,不該當運算符爲+
時,它會爲類似情況生成錯誤已被錯誤地用於非數字字符串值?
因此,這兩個問題使我無法接受解釋,即數字值文檔中引入的這個運算符是相同的+ (unary)
。由於在其他地方沒有其他地方提及它,因此可能會故意將其添加到該語言中。可能是一個錯誤。
問題看起來,當我們看到這樣的語句中不產生錯誤更嚴重的一個或者:
SELECT ++++++++'ABCDE'
我不知道是否有任何其他的編程語言在那裏它接受這些排序的陳述。但是,如果存在,那麼知道他們使用+ (unary)
運算符應用於字符串的目的是很好的。我無法想象任何用法!
UPDATE
這表示,這已經在早期版本的bug,但它不會因爲向後兼容的固定:
有根據上串一元運算符https://connect.microsoft.com/SQLServer/feedback/details/718176/concatenation-operator-not-working-procellly –
你的意思是? 「經過一番調查之後,這種行爲是在設計中的,因爲+是一元運算符,所以解析器接受」+「,在這種情況下,」+「被忽略。 更改此行爲有很多向後兼容的含義,因此我們不打算修改它,修復程序會爲應用程序代碼引入不必要的更改。「 –
RGO
是的,它在您引用的其他響應之後發佈,因此表示至少是就MS而言,這是「通過設計」而不是bug,該項目被設計爲「按設計」而不是「不會修復」 –