¿Cuál es el resultado correcto para esta consulta?

Encontré este rompecabezas en los comentarios aquí

CREATE TABLE r (b INT);

SELECT 1 FROM r HAVING 1=1;

SQL Server y PostgreSQL devuelven 1 fila.

MySQL y Oracle devuelven cero filas.

¿Cual es correcta? ¿O son ambos igualmente válidos?

Por el estándar:

SELECT 1 FROM r HAVING 1=1

medio

SELECT 1 FROM r GROUP BY () HAVING 1=1

Cita ISO / IEC 9075-2: 2011 7.10 Regla de sintaxis 1 (Parte de la definición de la cláusula HAVING):

Deja HCser el <having clause>. Deja que TEsea ​​lo <table expression>que contiene de inmediato HC. Si TEno contiene inmediatamente a <group by clause>, entonces " GROUP BY ()" está implícito. Sea Tel descriptor de la tabla definida por el <group by clause> GBCcontenido inmediato TEy Rsea ​​el resultado de GBC.

Ok, eso está bastante claro.

Afirmación: 1=1es verdadera condición de búsqueda. No proporcionaré ninguna cita para esto.

Ahora

SELECT 1 FROM r GROUP BY () HAVING 1=1

es equivalente a

SELECT 1 FROM r GROUP BY ()

Cita ISO / IEC 9075-2: 2011 7.10 Regla general 1:

El <search condition>se evalúa para cada grupo de R. El resultado de la <having clause>es una tabla agrupada de aquellos grupos de R para los cuales el resultado de la <search condition>es True.

Lógica: dado que la condición de búsqueda siempre es verdadera, el resultado es R, que es el resultado del grupo por expresión.

Lo siguiente es un extracto de las Reglas Generales de 7.9 (la definición del GRUPO POR CLÁUSULA)

1) Si no <where clause>se especifica no, entonces Tsea ​​el resultado de lo anterior <from clause>; de lo contrario, Tsea ​​el resultado de lo anterior <where clause>.

2) Caso:

a) Si no hay columnas de agrupación, el resultado de la <group by clause>tabla agrupada consiste Ten su único grupo.

Así podemos concluir que

FROM r GROUP BY ()

da como resultado una tabla agrupada, que consta de un grupo, con cero filas (ya que R está vacío).

Un extracto de las Reglas generales de 7.12, que define una Especificación de consulta (también conocida como una instrucción SELECT):

1) Caso:

a) Si Tno es una tabla agrupada, entonces [...]

b) Si Tes una tabla agrupada, entonces

Caso:

i) Si Ttiene 0 (cero) grupos, entonces deje que TEMP sea una tabla vacía.

ii) Si Ttiene uno o más grupos, cada uno <value expression>se aplica a cada grupo para obtener Tuna tabla TEMPde Mfilas, donde Mestá el número de grupos T. La icolumna -th de TEMP contiene los valores derivados de la evaluación de i-th <value expression>. [...]

2) Caso:

a) Si <set quantifier> DISTINCTno se especifica, entonces el resultado de la <query specification>es TEMP.

Por lo tanto, dado que la tabla tiene un grupo, debe tener una fila de resultados.

Así

SELECT 1 FROM r HAVING 1=1

debería devolver un conjunto de resultados de 1 fila.

QED

Cuando hay una HAVINGcláusula, sin una WHEREcláusula:

SELECT 1 FROM r HAVING 1=1;

... entonces GROUP BY ()está implícito. Entonces, la consulta debe ser equivalente a:

SELECT 1 FROM r GROUP BY () HAVING 1=1;

... que debería agrupar todas las filas de la tabla en un grupo (incluso si la tabla no tiene filas en absoluto, sigue siendo un grupo de 0 filas) y devolver 1 fila. El HAVINGcon la Truecondición no debería tener ningún efecto después de eso.

Desde un ángulo diferente, ¿cuántas filas debería devolver una consulta como esta?

SELECT COUNT(*), MAX(b) FROM r;

¿Uno, cero o "cero o uno, dependiendo de si la tabla está vacía o no"?

Creo que una fila, no importa cuántas filas rtenga.

Por lo que veo, parece que SQLServer y PostgerSQL no se molestan en mirar la tabla en absoluto:

CREATE TABLE r (b INT);
insert into r(b) values (1);
insert into r(b) values (2);
SELECT 1 FROM r HAVING 1=1;

También devuelve solo una fila. Aunque los documentos de SQLServer dicen

Cuando GROUP BY no se usa, HAVING se comporta como una cláusula WHERE.

eso no es cierto en este caso, en WHERE 1=1lugar de HAVINGdevolver el número adecuado de filas. Yo diría que es un error del optimizador (o al menos un error de documentación) ... el plan SQLServer muestra 'Análisis constante' en caso de HAVING'análisis de tabla' para WHERE...

El comportamiento de Oracle y Mysql me parece más lógico y correcto ...