Was ist das richtige Ergebnis für diese Abfrage?

Ich bin auf dieses Rätsel in den Kommentaren hier gestoßen

CREATE TABLE r (b INT);

SELECT 1 FROM r HAVING 1=1;

SQL Server und PostgreSQL geben 1 Zeile zurück.

MySQL und Oracle geben keine Zeilen zurück.

Welches ist richtig? Oder sind beide gleich gültig?

Nach dem Standard:

SELECT 1 FROM r HAVING 1=1

meint

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

Zitat ISO / IEC 9075-2: 2011 7.10 Syntaxregel 1 (Teil der Definition der HAVING-Klausel):

Lass HCdas sein <having clause>. Sei TEdas <table expression>, was sofort enthält HC. Wenn TEnicht sofort ein enthalten ist <group by clause>, dann ist " GROUP BY ()" implizit. Sei Tder Deskriptor der Tabelle, die durch das <group by clause> GBCsofort enthaltene in definiert ist, TEund sei Rdas Ergebnis von GBC.

Ok, so viel ist ziemlich klar.

Behauptung: 1=1ist wahre Suchbedingung. Ich werde dafür kein Zitat geben.

Jetzt

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

ist gleichwertig mit

SELECT 1 FROM r GROUP BY ()

Zitat ISO / IEC 9075-2: 2011 7.10 Allgemeine Regel 1:

Das <search condition>wird für jede Gruppe von ausgewertet R. Das Ergebnis von <having clause>ist eine gruppierte Tabelle der Gruppen von R, für die das Ergebnis von <search condition>True ist.

Logik: Da die Suchbedingung immer wahr ist R, ist das Ergebnis das Ergebnis der Gruppierung nach Ausdrücken.

Das Folgende ist ein Auszug aus den Allgemeinen Regeln von 7.9 (die Definition der GROUP BY CLAUSE)

1) Wenn nein <where clause>angegeben ist, sei Tdas Ergebnis des vorhergehenden <from clause>; Ansonsten sei Tdas Ergebnis des Vorhergehenden <where clause>.

2) Fall:

a) Wenn es keine Gruppierungsspalten gibt, ist das Ergebnis von <group by clause>die gruppierte Tabelle, die Tals einzige Gruppe besteht.

Daraus können wir schließen

FROM r GROUP BY ()

ergibt eine gruppierte Tabelle, bestehend aus einer Gruppe, mit null Zeilen (da R leer ist).

Ein Auszug aus den Allgemeinen Regeln von 7.12, in dem eine Abfragespezifikation (auch als SELECT-Anweisung bezeichnet) definiert ist:

1) Fall:

a) Wenn Tes sich nicht um eine gruppierte Tabelle handelt, dann [...]

b) Wenn Tes sich um eine gruppierte Tabelle handelt, dann

Fall:

i) Wenn Tes 0 (Null) Gruppen gibt, dann sei TEMP eine leere Tabelle.

ii) Wenn Teine oder mehr Gruppen, die jeweils dann <value expression>auf jede Gruppe angewandt wird , Twodurch man eine Tabelle TEMPvon MZeilen, wobei Mdie Anzahl der Gruppen in T. Die i-te Spalte von TEMP enthält die Werte, die durch die Auswertung der i-ten abgeleitet wurden <value expression>. [...]

2) Fall:

a) Wenn das <set quantifier> DISTINCTnicht angegeben wird, dann ist das Ergebnis der <query specification>ist TEMP.

Da die Tabelle eine Gruppe enthält, muss sie daher eine Ergebniszeile enthalten.

Somit

SELECT 1 FROM r HAVING 1=1

sollte eine 1-zeilige Ergebnismenge zurückgeben.

QED

Wenn es eine HAVINGKlausel ohne WHEREKlausel gibt:

SELECT 1 FROM r HAVING 1=1;

... dann GROUP BY ()ist implizit. Die Abfrage sollte also äquivalent sein zu:

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

... die alle Zeilen der Tabelle in einer Gruppe gruppieren sollte (auch wenn die Tabelle überhaupt keine Zeilen enthält - es ist immer noch eine Gruppe von 0 Zeilen) und 1 Zeile zurückgeben. Die HAVINGmit der TrueBedingung sollte danach überhaupt keine Wirkung haben.

Wie viele Zeilen sollte eine solche Abfrage aus einem anderen Blickwinkel zurückgeben?

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

Eins, Null oder "Null oder Eins, je nachdem, ob die Tabelle leer ist oder nicht"?

Ich denke, eine Zeile, egal wie viele Zeilen rhat.

Wie ich sehe, scheinen SQLServer und PostgerSQL überhaupt nicht in die Tabelle zu schauen:

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

Gibt auch nur eine Zeile zurück. Auch wenn SQLServer docs sagt

Wenn GROUP BY nicht verwendet wird, verhält sich HAVING wie eine WHERE-Klausel.

Dies ist in diesem Fall nicht der Fall, WHERE 1=1sondern HAVINGgibt die richtige Anzahl von Zeilen zurück. Ich würde sagen, es ist ein Optimierungsfehler (oder zumindest ein Dokumentationsfehler) ... Der SQLServer-Plan zeigt "Constant Scan" für den Fall HAVINGund "Table Scan" für WHERE...

Das Verhalten von Oracle und MySQL erscheint mir logischer und korrekter ...