Evaluación SQL de las cláusulas IF

Question

Disculpas si esto no es adecuado, pero en realidad se trata de un 'por qué' en lugar de un 'cómo'. No estoy seguro de que sea adecuado, pero no conozco un lugar mejor para preguntar y no puedo pensar cómo expresar un google para obtener lo que estoy buscando.

IF 'hell' = 'freezing over' 
    BEGIN 
    SELECT log(0) 
    END 

Mire esa afirmación. No hay mundo en el que la cláusula IF sea verdadera. Si intento ejecutarlo, estoy esperando que SQL salte la cláusula IF y se mueva hasta el final. En su lugar obtengo:

An invalid floating point operation occurred. 

Esto es extraño. Así que supongo que esa es la forma en que SQL lo hace. Excepto ...

IF 'hell' = 'freezing over' 
    BEGIN 
    SELECT 1/0 
    END 

No hay ningún error aquí. La declaración en la cláusula IF aún debe generar un error. ¿Alguien podría explicar por qué esto no está sucediendo?

Esto surgió mientras se depuraba un conjunto masivo de calcos SQL donde EXP (SUM (LOG())) se usa para acumular datos dentro de una cláusula if. Puedo alterar el código para evitar que vuelva a suceder, pero ¿por qué está evaluando algo dentro de una cláusula IF que no se cumple?

Saludos.

EDITAR: Diversión adicional. ¿Trata de atraparlo? Pffft

IF 1=2 
    BEGIN 
     BEGIN TRY 
      SELECT SQRT(-1) 
     END TRY 
     BEGIN CATCH 
     END CATCH 
    END 

no matemática:

IF 1=2 
    BEGIN 
    SELECT SUBSTRING('hello',-1,-1) 
    END 

Answer 1

Mi conjetura sería que log(0) se evalúa de manera efectiva antes de tiempo debido a constant-folding mientras que 1/0 no es, ya sea debido a su estimación de cardinalidad o más probablemente el hecho de que el ajuste ANSI_WARNINGS afectará el resultado deseado de una división por cero (desbordamiento vs NULO).

Answer 2

El analizador simplemente no tiene la inteligencia para seguir su lógica SI. Consideremos el siguiente ejemplo:

IF (1 = 0) 
BEGIN 
    CREATE TABLE #t(x INT): 
END 
ELSE 
BEGIN 
    CREATE TABLE #t(x INT): 
END 

Si lo ejecutas o incluso sólo analizarlo, el analizador se ve en todos los CREATE TABLE instrucciones del lote y determina que ha intentado crear la tabla dos veces (la primera copia, obviamente, doesn debe existir para que esto suceda). Resultado:

Msg 2714, nivel 16, estado 1, línea 7
Ya hay un objeto denominado '#t' en la base de datos.

Realmente no sé si tengo una mejor respuesta para usted que el analizador no es tan inteligente como usted.

Puede vencer al analizador posponiendo el problema hasta el tiempo de ejecución mediante SQL dinámico, p. Ej.

IF 'hell' = 'freezing over' 
BEGIN 
    EXEC sp_executesql N'SELECT log(0);'; 
END 

Pero entonces tendría que preguntarse, ¿cuál es el punto de establecer el andamiaje para una condición que nunca va a ser verdad, y la emisión de una declaración de que usted sabe que va a error?

Answer 3

Claramente, hay algunas expresiones que el compilador de SQL está tratando de evaluar en tiempo de compilación versus en tiempo de ejecución. Mi suposición es que una división no se considera demasiado cara, por lo que se pospone al tiempo de ejecución. Por otro lado, algo realmente complicado como un log() es costoso y quieren hacerlo en tiempo de compilación.

Esto es una suposición. También significa que tales diferencias no son deterministas.Debe averiguar cuál funciona o no funciona en una secuencia de comandos en particular, y el comportamiento puede cambiar entre lanzamientos de la base de datos.

Answer 4

Si intento plazo que estoy esperando SQL para saltar más allá de la cláusula IF y pasar a la final.

Cuando se ejecuta el lote tres cosas suceden

1. Su SQL se analiza

2. Su SQL se compila

3. se ejecuta SQL

Lo que es desconocido rtunate es que los errores tanto de compilación como de ejecución en un lote en el servidor SQL dan como resultado el mismo mensaje "Consulta completada con errores". Por lo que permite utilizar un procedimiento en donde es más fácil ver la diferencia

Considere el siguiente

Create proc compiletime 
as 
SELECT log(0) 
SELECT SQRT(-1) 
SELECT SUBSTRING('hello',-1,-1) 
SELECT 1/0 

Este procedimiento analiza bien. Sin embargo, no se puede compilar a menos que eliminemos los primeros tres SELECT porque tenemos algunas constantes que no son válidas como parámetros. Sería bueno si SELECT 1/0 también causó un error de tiempo de compilación en lugar de un error de tiempo de ejecución, pero como @Alex K señala que el comportamiento se basa en ANSI_WARNINGS por lo que no es un error de tiempo de compilación.

Es por eso que vemos diferencias entre los dos primeros. También explica por qué TRY CATCH no funcionó ya que es un error de tiempo de compilación.

Ahora, ¿por qué el servidor SQL compila el código inalcanzable? Porque en general para saber que es inalcanzable requiere una solución al problema de detención. Puede solucionarlo para algunos casos, pero luego esto ...

DECLARE @x as integer 
SET @x = SomeFunction() 
If (1 = @x) 
    SomeCompiletime error 

tendrían un comportamiento diferente que es aún más confuso.

if (1=0) 
    SomeCompiletime error