Qual è il risultato corretto per questa query?

Mi sono imbattuto in questo puzzle nei commenti qui

CREATE TABLE r (b INT);

SELECT 1 FROM r HAVING 1=1;

SQL Server e PostgreSQL restituiscono 1 riga.

MySQL e Oracle restituiscono zero righe.

Che è corretto? O sono entrambi ugualmente validi?

Secondo lo standard:

SELECT 1 FROM r HAVING 1=1

si intende

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

Visto ISO / IEC 9075-2: 2011 7.10 Sintassi Regola 1 (Parte della definizione della clausola HAVING):

Lascia che HCsia il <having clause>. Lascia che TEsia quello <table expression>che contiene immediatamente HC. Se TEnon contiene immediatamente a <group by clause>, allora " GROUP BY ()" è implicito. Lascia che Tsia il descrittore della tabella definita dal <group by clause> GBCcontenuto immediatamente contenuto TEe Rsia il risultato di GBC.

Ok, è molto chiaro.

Asserzione: 1=1è la vera condizione di ricerca. Non fornirò alcuna citazione per questo.

Adesso

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

è equivalente a

SELECT 1 FROM r GROUP BY ()

Visto ISO / IEC 9075-2: 2011 7.10 Regola generale 1:

La <search condition>viene valutata per ciascun gruppo di R. Il risultato di <having clause>è una tabella raggruppata di quei gruppi di R per i quali il risultato di <search condition>è Vero.

Logica: poiché la condizione di ricerca è sempre vera, il risultato è R, che è il risultato del gruppo in base all'espressione.

Quello che segue è un estratto delle Regole generali di 7.9 (la definizione del GRUPPO PER CLAUSOLA)

1) Se non <where clause>viene specificato no , allora Tsia il risultato del precedente <from clause>; altrimenti, Tsia il risultato del precedente <where clause>.

2) Caso:

a) Se non ci sono colonne di raggruppamento, il risultato di <group by clause>è la tabella raggruppata costituita dal Tsuo unico gruppo.

Quindi possiamo concludere che

FROM r GROUP BY ()

risulta in una tabella raggruppata, composta da un gruppo, con zero righe (poiché R è vuota).

Un estratto dalle Regole generali di 7.12, che definisce una specifica di query (aka un'istruzione SELECT):

1) Caso:

a) Se Tnon è una tabella raggruppata, [...]

b) Se Tè una tabella raggruppata, allora

Astuccio:

i) Se Tha 0 (zero) gruppi, allora lascia che TEMP sia una tabella vuota.

ii) Se Tha uno o più gruppi, ognuno <value expression>viene applicato a ciascun gruppo di Trestituire una tabella TEMPdi Mrighe, dove Mè il numero di gruppi in T. La icolonna -th di TEMP contiene i valori derivati ​​dalla valutazione del i-th <value expression>. [...]

2) Caso:

a) Se <set quantifier> DISTINCTnon è specificato, il risultato di <query specification>è TEMP.

Pertanto, poiché la tabella ha un gruppo, deve avere una riga di risultati.

così

SELECT 1 FROM r HAVING 1=1

dovrebbe restituire un set di risultati di 1 riga.

QED

Quando c'è una HAVINGclausola, senza una WHEREclausola:

SELECT 1 FROM r HAVING 1=1;

... allora GROUP BY ()è implicito. Pertanto, la query dovrebbe essere equivalente a:

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

... che dovrebbe raggruppare tutte le righe della tabella in un gruppo (anche se la tabella non ha alcuna riga - è ancora un gruppo di 0 righe) e restituire 1 riga. Il HAVINGcon la Truecondizione dovrebbe avere alcun effetto a tutti dopo.

Da un'angolazione diversa, quante righe dovrebbe restituire una query come questa?

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

Uno, zero o "zero o uno, a seconda che la tabella sia vuota o meno"?

Penso che una riga, indipendentemente da quante righe rabbia.

Da quello che vedo, sembra che SQL Server e PostgerSQL non si preoccupino affatto di guardare la tabella:

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

restituisce anche solo una riga. Anche se i documenti di SQLServer dicono

Quando GROUP BY non viene utilizzato, HAVING si comporta come una clausola WHERE.

ciò non è vero in questo caso, WHERE 1=1invece di HAVINGrestituire il numero corretto di righe. Direi che è un bug di ottimizzazione (o almeno un bug di documentazione) ... Il piano SQL Server mostra "Scansione costante" in caso di HAVING"Scansione tabella" per WHERE...

Il comportamento di Oracle e Mysql mi sembra più logico e corretto ...