Блог

Я удивлен! Приведенное ниже утверждение справедливо в SQL SERVER :

 SELECT   'ABCDEF'
  

SQL Server Определен как Unary оператор для строковых типов?

Вот мой собственный ответ на этот вопрос (пожалуйста, также ознакомьтесь с обновлением в конце):

Нет, в строковых выражениях не определен такой унарный оператор. Возможно, что это ошибка.

Объяснение:

Данное утверждение является допустимым, и оно генерирует приведенный ниже результат:

 (No column name) 
----------------
ABCDEF
(1 row(s) affected)
  

что эквивалентно выполнению SELECT инструкции без использования знака:

 SELECT  'ABCDEF'
  

Компиляция без каких-либо ошибок, фактически выполняемая успешно, создает впечатление, что выполняется как Unary операция над данной строкой. Однако в официальной T-SQL документации такой оператор не упоминается. Фактически, в разделе, озаглавленном «Строковые операторы«, появляется в двух строковых операциях, которые являются (String Concatenation) и = (String Concatenation) ; но ни одна из них не является Unary операцией. Кроме того, в разделе, озаглавленном «Унарные операторы«, были введены три оператора, только один из которых является (Positive) оператором. Однако для этого единственного, который кажется уместным, вскоре становится ясно, что этот оператор тоже не имеет ничего общего с нечисловыми строковыми значениями, поскольку в объяснении для (Positive) 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) оператор, применяемый к строке. Я не могу представить никакого использования!

Обновить

Здесь говорится, что это была ошибка в более ранних версиях, но она не будет исправлена из-за обратной совместимости:

После некоторого исследования выяснилось, что такое поведение является преднамеренным, поскольку является унарным оператором. Таким образом, анализатор принимает » , а ‘ ‘ в этом случае просто игнорируется. Изменение этого поведения имеет много последствий для обратной совместимости, поэтому мы не собираемся его менять, и исправление внесет ненужные изменения в код приложения.