Apa hasil yang benar untuk permintaan ini?

Saya menemukan puzzle ini di komentar di sini

CREATE TABLE r (b INT);

SELECT 1 FROM r HAVING 1=1;

SQL Server dan PostgreSQL mengembalikan 1 baris.

MySQL dan Oracle mengembalikan nol baris.

Yang mana yang benar? Atau keduanya sama-sama valid?

Sesuai standar:

SELECT 1 FROM r HAVING 1=1

cara

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

Kutipan ISO / IEC 9075-2: 2011 7.10 Sintaks Aturan 1 (Bagian dari definisi klausa HAVING):

Biarkan HCsaja <having clause>. Biarkan TEmenjadi <table expression>yang berisi HC. Jika TEtidak segera mengandung a <group by clause>, maka " GROUP BY ()" adalah implisit. Membiarkan Tmenjadi deskriptor dari tabel yang didefinisikan oleh <group by clause> GBCsegera terkandung TEdan biarkan Rmenjadi hasil GBC.

Ok jadi itu cukup jelas.

Pernyataan: 1=1adalah kondisi pencarian yang sebenarnya. Saya tidak akan memberikan kutipan untuk ini.

Sekarang

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

setara dengan

SELECT 1 FROM r GROUP BY ()

Kutipan ISO / IEC 9075-2: 2011 7.10 Aturan Umum 1:

The <search condition>dievaluasi untuk setiap kelompok R. Hasil dari <having clause>adalah tabel dikelompokkan dari kelompok-kelompok R yang hasilnya <search condition>benar.

Logika: Karena kondisi pencarian selalu benar, hasilnya adalah R, yang merupakan hasil grup dengan ekspresi.

Berikut ini adalah kutipan dari Peraturan Umum 7.9 (definisi GROUP BY CLAUSE)

1) Jika tidak <where clause>ditentukan, maka biarkan Tmenjadi hasil dari pendahulunya <from clause>; jika tidak, biarkan Tmenjadi hasil dari sebelumnya <where clause>.

2) Kasus:

a) Jika tidak ada kolom pengelompokan, maka hasil dari <group by clause>adalah tabel dikelompokkan terdiri dari Tsebagai satu-satunya grup.

Dengan demikian kita dapat menyimpulkan itu

FROM r GROUP BY ()

menghasilkan tabel yang dikelompokkan, terdiri dari satu grup, dengan nol baris (karena R kosong).

Kutipan dari Aturan Umum 7.12, yang mendefinisikan Spesifikasi Kueri (alias pernyataan SELECT):

1) Kasus:

a) Jika Tbukan tabel yang dikelompokkan, maka [...]

b) Jika Ttabel dikelompokkan, maka

Kasus:

i) Jika Tmemiliki 0 (nol) grup, maka biarkan TEMP menjadi tabel kosong.

ii) Jika Tmemiliki satu atau lebih kelompok, maka setiap <value expression>diterapkan untuk setiap kelompok Tmenghasilkan sebuah meja TEMPdari Mbaris, di mana Madalah jumlah kelompok di T. The ikolom -th TEMP mengandung nilai-nilai yang diperoleh evaluasi i-th <value expression>. [...]

2) Kasus:

a) Jika <set quantifier> DISTINCTtidak ditentukan, maka hasil dari <query specification>is TEMP.

Oleh karena itu karena tabel memiliki satu grup, itu harus memiliki satu baris hasil.

Jadi

SELECT 1 FROM r HAVING 1=1

harus mengembalikan set hasil 1 baris.

QED

Ketika ada HAVINGklausa, tanpa WHEREklausa:

SELECT 1 FROM r HAVING 1=1;

... maka GROUP BY ()tersirat. Jadi, kueri harus sama dengan:

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

... yang seharusnya mengelompokkan semua baris tabel ke dalam satu grup (bahkan jika tabel tidak memiliki baris sama sekali - itu masih satu grup dari 0 baris) dan mengembalikan 1 baris. The HAVINGdengan Truekondisi seharusnya tidak berpengaruh sama sekali setelah itu.

Dari sudut pandang yang berbeda, berapa banyak baris yang harus kueri seperti ini kembali?

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

Satu, nol atau "nol atau satu, tergantung pada apakah tabelnya kosong atau tidak"?

Saya pikir satu baris, tidak peduli berapa banyak baris yang rdimiliki.

Dari apa yang saya lihat, sepertinya SQLServer dan PostgerSQL tidak repot melihat ke dalam tabel sama sekali:

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

juga mengembalikan hanya satu baris. Meskipun kata SQLServer docs

Ketika GROUP BY tidak digunakan, HAVING berperilaku seperti klausa WHERE.

itu tidak benar dalam kasus ini - WHERE 1=1alih - alih HAVINGmengembalikan jumlah baris yang tepat. Saya akan mengatakan itu bug pengoptimal (atau setidaknya bug dokumentasi) ... Rencana SQLServer menunjukkan 'Pemindaian konstan' dalam kasus HAVINGdan 'pemindaian tabel' untuk WHERE...

Perilaku Oracle dan Mysql tampaknya lebih logis dan benar bagi saya ...