Qual é o resultado correto para esta consulta?

Me deparei com este quebra-cabeça nos comentários aqui

CREATE TABLE r (b INT);

SELECT 1 FROM r HAVING 1=1;

SQL Server e PostgreSQL retornam 1 linha.

MySQL e Oracle retornam zero linhas.

Qual é correto? Ou ambos são igualmente válidos?

De acordo com o padrão:

SELECT 1 FROM r HAVING 1=1

significa

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

Citação ISO / IEC 9075-2: 2011 7.10 Regra de sintaxe 1 (parte da definição da cláusula HAVING):

Let HCSer o <having clause>. Let TESer o <table expression>que contém imediatamente HC. Se TEnão contiver imediatamente um <group by clause>, então " GROUP BY ()" estará implícito. Let TSeja o descritor da tabela definida pelo <group by clause> GBCimediatamente contido TEe Rseja o resultado de GBC.

Ok, então isso é bem claro.

Afirmação: 1=1é verdadeira condição de pesquisa. Não fornecerei nenhuma citação para isso.

Agora

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

é equivalente a

SELECT 1 FROM r GROUP BY ()

Citação ISO / IEC 9075-2: 2011 7.10 Regra Geral 1:

O <search condition>é avaliado para cada grupo de R. O resultado de <having clause>é uma tabela agrupada dos grupos de R para os quais o resultado de <search condition>é True.

Lógica: como a condição de pesquisa é sempre verdadeira, o resultado é R, que é o resultado do grupo por expressão.

A seguir, um trecho das Regras Gerais de 7.9 (a definição do GRUPO POR CLÁUSULA)

1) Se não <where clause>for especificado, Tseja o resultado do anterior <from clause>; caso contrário, Tseja o resultado do anterior <where clause>.

2) Caso:

a) Se não houver colunas de agrupamento, o resultado da <group by clause>é a tabela agrupada que consiste Tem seu único grupo.

Assim, podemos concluir que

FROM r GROUP BY ()

resulta em uma tabela agrupada, composta por um grupo, com zero linhas (já que R está vazio).

Um trecho das Regras Gerais da 7.12, que define uma Especificação de Consulta (também conhecida como instrução SELECT):

1) Caso:

a) Se Tnão for uma tabela agrupada, então [...]

b) Se Tfor uma tabela agrupada, então

Caso:

i) Se Ttiver 0 (zero) grupos, deixe TEMP ser uma tabela vazia.

ii) Se Ttiver um ou mais grupos, cada um <value expression>será aplicado a cada grupo que Tproduz uma tabela TEMPde Mlinhas, onde Mestá o número de grupos em T. A icoluna -th do TEMP contém os valores derivados pela avaliação da i-th <value expression>. [...]

2) Caso:

a) Se <set quantifier> DISTINCTnão for especificado, o resultado <query specification>será TEMP.

Portanto, como a tabela possui um grupo, ela deve ter uma linha de resultado.

portanto

SELECT 1 FROM r HAVING 1=1

deve retornar um conjunto de resultados de 1 linha.

QED

Quando existe uma HAVINGcláusula, sem uma WHEREcláusula:

SELECT 1 FROM r HAVING 1=1;

... então GROUP BY ()está implícito. Portanto, a consulta deve ser equivalente a:

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

... que deve agrupar todas as linhas da tabela em um grupo (mesmo que a tabela não tenha linhas - ainda é um grupo de 0 linhas) e retorna 1 linha. O HAVINGcom a Truecondição não deve ter efeito algum depois disso.

De um ângulo diferente, quantas linhas uma consulta como essa deve retornar?

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

Um, zero ou "zero ou um, dependendo se a tabela está vazia ou não"?

Eu acho que uma linha, não importa quantas linhas rtem.

Pelo que vejo, parece que o SQLServer e o PostgerSQL não se incomodam em olhar para a tabela:

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

também retorna apenas uma linha. Embora os documentos do SQLServer digam

Quando GROUP BY não é usado, HAVING se comporta como uma cláusula WHERE.

isso não é verdade neste caso - em WHERE 1=1vez de HAVINGretornar o número adequado de linhas. Eu diria que é um bug do otimizador (ou pelo menos um bug na documentação) ... O plano do SQLServer mostra 'Constant scan' no caso de HAVINGe 'table scan' for WHERE...

O comportamento do Oracle e Mysql parece mais lógico e correto para mim ...