QUERY

GOOGLE'S OWN PUBLISHED EXAMPLE, translated only in its column identifiers. The query language reference prints the query `select name where salary > 700` over this exact table and then prints its output in full: John, Mike. Here `name` is column A and `salary` is column C. ARRAY RESULT: compared over an explicit check_range in row-major order. THE DATA IS GOOGLE'S, THE COLUMN LETTERS ARE NOT. Both Google pages build their examples on the same six-employee table (John/Dave/Sally/Eng, Ben/Dana/Sales, Mike/Marketing, with salaries 1000, 500, 600, 400, 350, 800 and ages 35, 27, 30, 32, 25, 24), and this file uses it. The query language reference names its columns by the identifiers `name`, `dept`, `salary`, ... because its examples run against a data source with named columns; inside the QUERY function the identifiers are the SHEET'S column letters, which the reference states flatly: "in a Google Spreadsheet, column identifiers are the one or two character column letter (A, B, C, ...)" and "column IDs in spreadsheets are always letters; the column heading text shown in the published spreadsheet are labels, not IDs. You must use the ID, not the label, in your query string." So `salary` becomes C here and `dept` becomes B. The lunchTime, hireDate and seniorityStartTime columns are omitted: they are time and date values whose text form would put a locale into every assertion. The range is HEADERLESS and every case passes headers = 0 explicitly, rather than relying on the `headers` argument's documented fallback ("If omitted or set to -1, the value is guessed based on the content of data") -- a guess is not something to assert against. TWO GAPS IN THE DOCUMENTATION THAT SHAPED THIS FILE. (1) NEITHER PAGE STATES WHETHER A QUERY RESULT CARRIES A HEADER ROW. The function page is silent; the language reference never uses the phrase. The only primary-source evidence either way is the behaviour of the example sheet the function page embeds, where an aggregate query does emit one. Rather than assert a header row this corpus cannot cite a sentence for, the aggregate cases below are asserted through SUM and COUNTA, which are unaffected by a leading text row. (2) NEITHER PAGE NAMES ANY ERROR VALUE. There is no statement anywhere about what an invalid query, an empty result or a type-mismatched column returns, so this corpus asserts no error behaviour for QUERY at all and every case below is written to match at least one row. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.

DERIVED from the select clause's documented purpose: "Selects which columns to return, and IN WHAT ORDER." The rows are the two the previous case returns, so only the column order is under test; row order is unchanged because no order by clause is given. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343.

DERIVED. Three employees are in Eng. The language reference has a dedicated case-sensitivity section, quoted in full: "Identifiers and string literals are case-sensitive. All other language elements are case-insensitive." It also fixes the quoting: "A string literal should be enclosed in either single or double quotes", and single quotes are used here so the query string's own double quotes are not disturbed. The three Eng employees come back in source order, which is also exactly the output QUERY's own embedded example sheet publishes for the equivalent Col-notation query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

DERIVED, and the pair that makes the previous case mean something. The reference's own remedy is quoted there: "String matching is case sensitive (you can use upper() or lower() scalar functions to work around that)." A lowercase literal that matches through lower() must not match without it, so this case and the one above must return the same three rows while a bare 'eng' returns none. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

DERIVED. The reference documents max() as "Returns the maximum value in the column for a group" and group by as "A single row is created for each distinct combination of values in the group-by clause". The three departments' maximum salaries are Eng 1000, Marketing 800 and Sales 400, which sum to 2200 -- and the function page's own embedded example sheet runs the same query shape, `select B, MAX(D) group by B`, and prints exactly those three values. SUM is used rather than a spilled comparison precisely because neither page says whether an aggregate result carries a header row; SUM ignores a leading text cell either way. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED. The reference's order by example is `order by dept, salary desc` and its limit example is `limit 100`; the clause order used here, order by before limit, is the order the reference's own clause table mandates ("The order of the clauses must be as follows": select, where, group by, pivot, order by, limit, offset, label, format, options). Salaries descending run 1000, 800, 600, 500, 400, 350, so the first two are John and Mike. NOTE THAT `asc` IS NEVER SHOWN in the reference's order by section and no default direction is stated, which is why only the explicit `desc` form is asserted. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED from the one sentence that fixes the interaction: "The offset clause is used to skip a given number of first rows. If a limit clause is used, offset is applied first: for example, limit 15 offset 30 returns rows 31 through 45." Skipping one row of the descending salary order and taking two gives Mike (800) and Sally (600). ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED. The reference defines contains as "A substring match. whole contains part is true if part is anywhere within whole", and its own example spells out the case rule: "where name contains 'John'" matches 'John', 'John Adams', 'Long John Silver' but NOT 'john adams'. Of the six names, Dave, Sally and Dana contain a lowercase 'a'; John, Ben and Mike do not -- and Dana is the case that matters, since an uppercase-insensitive match would also pull in nothing extra here but a case-FOLDING one would not change the answer, whereas 'A' as the pattern would return only Dave and Dana's neighbours. The three are returned in source order. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

THE TWO PAGES DISAGREE HERE AND THIS CASE EXECUTES THE ONE THAT IS SPECIFIC TO SHEETS. The query language reference says identifiers in a spreadsheet are "always letters" and the string `Col1` appears nowhere on it. QUERY's own function page says, in its Examples section, "QUERY can accept either \"Col\" notation or \"A, B\" notation", and its embedded example sheet runs `select Col1 where Col2 = 'Eng'` against a sheet range and returns John, Dave, Sally -- the same three this case counts. Neither page says when the Col form becomes REQUIRED rather than merely accepted, so this corpus asserts only that it is accepted and returns the same three rows as the letter form two cases above -- which are also the three names Google's own embedded sheet prints for this exact query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

GOOGLE'S OWN PUBLISHED EXAMPLE, translated only in its column identifiers. The query language reference prints the query `select name where salary > 700` over this exact table and then prints its output in full: John, Mike. Here `name` is column A and `salary` is column C. ARRAY RESULT: compared over an explicit check_range in row-major order. THE DATA IS GOOGLE'S, THE COLUMN LETTERS ARE NOT. Both Google pages build their examples on the same six-employee table (John/Dave/Sally/Eng, Ben/Dana/Sales, Mike/Marketing, with salaries 1000, 500, 600, 400, 350, 800 and ages 35, 27, 30, 32, 25, 24), and this file uses it. The query language reference names its columns by the identifiers `name`, `dept`, `salary`, ... because its examples run against a data source with named columns; inside the QUERY function the identifiers are the SHEET'S column letters, which the reference states flatly: "in a Google Spreadsheet, column identifiers are the one or two character column letter (A, B, C, ...)" and "column IDs in spreadsheets are always letters; the column heading text shown in the published spreadsheet are labels, not IDs. You must use the ID, not the label, in your query string." So `salary` becomes C here and `dept` becomes B. The lunchTime, hireDate and seniorityStartTime columns are omitted: they are time and date values whose text form would put a locale into every assertion. The range is HEADERLESS and every case passes headers = 0 explicitly, rather than relying on the `headers` argument's documented fallback ("If omitted or set to -1, the value is guessed based on the content of data") -- a guess is not something to assert against. TWO GAPS IN THE DOCUMENTATION THAT SHAPED THIS FILE. (1) NEITHER PAGE STATES WHETHER A QUERY RESULT CARRIES A HEADER ROW. The function page is silent; the language reference never uses the phrase. The only primary-source evidence either way is the behaviour of the example sheet the function page embeds, where an aggregate query does emit one. Rather than assert a header row this corpus cannot cite a sentence for, the aggregate cases below are asserted through SUM and COUNTA, which are unaffected by a leading text row. (2) NEITHER PAGE NAMES ANY ERROR VALUE. There is no statement anywhere about what an invalid query, an empty result or a type-mismatched column returns, so this corpus asserts no error behaviour for QUERY at all and every case below is written to match at least one row. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.

DERIVED from the select clause's documented purpose: "Selects which columns to return, and IN WHAT ORDER." The rows are the two the previous case returns, so only the column order is under test; row order is unchanged because no order by clause is given. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343.

DERIVED. Three employees are in Eng. The language reference has a dedicated case-sensitivity section, quoted in full: "Identifiers and string literals are case-sensitive. All other language elements are case-insensitive." It also fixes the quoting: "A string literal should be enclosed in either single or double quotes", and single quotes are used here so the query string's own double quotes are not disturbed. The three Eng employees come back in source order, which is also exactly the output QUERY's own embedded example sheet publishes for the equivalent Col-notation query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

DERIVED, and the pair that makes the previous case mean something. The reference's own remedy is quoted there: "String matching is case sensitive (you can use upper() or lower() scalar functions to work around that)." A lowercase literal that matches through lower() must not match without it, so this case and the one above must return the same three rows while a bare 'eng' returns none. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

DERIVED. The reference documents max() as "Returns the maximum value in the column for a group" and group by as "A single row is created for each distinct combination of values in the group-by clause". The three departments' maximum salaries are Eng 1000, Marketing 800 and Sales 400, which sum to 2200 -- and the function page's own embedded example sheet runs the same query shape, `select B, MAX(D) group by B`, and prints exactly those three values. SUM is used rather than a spilled comparison precisely because neither page says whether an aggregate result carries a header row; SUM ignores a leading text cell either way. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED. The reference's order by example is `order by dept, salary desc` and its limit example is `limit 100`; the clause order used here, order by before limit, is the order the reference's own clause table mandates ("The order of the clauses must be as follows": select, where, group by, pivot, order by, limit, offset, label, format, options). Salaries descending run 1000, 800, 600, 500, 400, 350, so the first two are John and Mike. NOTE THAT `asc` IS NEVER SHOWN in the reference's order by section and no default direction is stated, which is why only the explicit `desc` form is asserted. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED from the one sentence that fixes the interaction: "The offset clause is used to skip a given number of first rows. If a limit clause is used, offset is applied first: for example, limit 15 offset 30 returns rows 31 through 45." Skipping one row of the descending salary order and taking two gives Mike (800) and Sally (600). ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED. The reference defines contains as "A substring match. whole contains part is true if part is anywhere within whole", and its own example spells out the case rule: "where name contains 'John'" matches 'John', 'John Adams', 'Long John Silver' but NOT 'john adams'. Of the six names, Dave, Sally and Dana contain a lowercase 'a'; John, Ben and Mike do not -- and Dana is the case that matters, since an uppercase-insensitive match would also pull in nothing extra here but a case-FOLDING one would not change the answer, whereas 'A' as the pattern would return only Dave and Dana's neighbours. The three are returned in source order. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

THE TWO PAGES DISAGREE HERE AND THIS CASE EXECUTES THE ONE THAT IS SPECIFIC TO SHEETS. The query language reference says identifiers in a spreadsheet are "always letters" and the string `Col1` appears nowhere on it. QUERY's own function page says, in its Examples section, "QUERY can accept either \"Col\" notation or \"A, B\" notation", and its embedded example sheet runs `select Col1 where Col2 = 'Eng'` against a sheet range and returns John, Dave, Sally -- the same three this case counts. Neither page says when the Col form becomes REQUIRED rather than merely accepted, so this corpus asserts only that it is accepted and returns the same three rows as the letter form two cases above -- which are also the three names Google's own embedded sheet prints for this exact query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

GOOGLE'S OWN PUBLISHED EXAMPLE, translated only in its column identifiers. The query language reference prints the query `select name where salary > 700` over this exact table and then prints its output in full: John, Mike. Here `name` is column A and `salary` is column C. ARRAY RESULT: compared over an explicit check_range in row-major order. THE DATA IS GOOGLE'S, THE COLUMN LETTERS ARE NOT. Both Google pages build their examples on the same six-employee table (John/Dave/Sally/Eng, Ben/Dana/Sales, Mike/Marketing, with salaries 1000, 500, 600, 400, 350, 800 and ages 35, 27, 30, 32, 25, 24), and this file uses it. The query language reference names its columns by the identifiers `name`, `dept`, `salary`, ... because its examples run against a data source with named columns; inside the QUERY function the identifiers are the SHEET'S column letters, which the reference states flatly: "in a Google Spreadsheet, column identifiers are the one or two character column letter (A, B, C, ...)" and "column IDs in spreadsheets are always letters; the column heading text shown in the published spreadsheet are labels, not IDs. You must use the ID, not the label, in your query string." So `salary` becomes C here and `dept` becomes B. The lunchTime, hireDate and seniorityStartTime columns are omitted: they are time and date values whose text form would put a locale into every assertion. The range is HEADERLESS and every case passes headers = 0 explicitly, rather than relying on the `headers` argument's documented fallback ("If omitted or set to -1, the value is guessed based on the content of data") -- a guess is not something to assert against. TWO GAPS IN THE DOCUMENTATION THAT SHAPED THIS FILE. (1) NEITHER PAGE STATES WHETHER A QUERY RESULT CARRIES A HEADER ROW. The function page is silent; the language reference never uses the phrase. The only primary-source evidence either way is the behaviour of the example sheet the function page embeds, where an aggregate query does emit one. Rather than assert a header row this corpus cannot cite a sentence for, the aggregate cases below are asserted through SUM and COUNTA, which are unaffected by a leading text row. (2) NEITHER PAGE NAMES ANY ERROR VALUE. There is no statement anywhere about what an invalid query, an empty result or a type-mismatched column returns, so this corpus asserts no error behaviour for QUERY at all and every case below is written to match at least one row. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.

DERIVED from the select clause's documented purpose: "Selects which columns to return, and IN WHAT ORDER." The rows are the two the previous case returns, so only the column order is under test; row order is unchanged because no order by clause is given. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343.

DERIVED. Three employees are in Eng. The language reference has a dedicated case-sensitivity section, quoted in full: "Identifiers and string literals are case-sensitive. All other language elements are case-insensitive." It also fixes the quoting: "A string literal should be enclosed in either single or double quotes", and single quotes are used here so the query string's own double quotes are not disturbed. The three Eng employees come back in source order, which is also exactly the output QUERY's own embedded example sheet publishes for the equivalent Col-notation query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

DERIVED, and the pair that makes the previous case mean something. The reference's own remedy is quoted there: "String matching is case sensitive (you can use upper() or lower() scalar functions to work around that)." A lowercase literal that matches through lower() must not match without it, so this case and the one above must return the same three rows while a bare 'eng' returns none. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

DERIVED. The reference documents max() as "Returns the maximum value in the column for a group" and group by as "A single row is created for each distinct combination of values in the group-by clause". The three departments' maximum salaries are Eng 1000, Marketing 800 and Sales 400, which sum to 2200 -- and the function page's own embedded example sheet runs the same query shape, `select B, MAX(D) group by B`, and prints exactly those three values. SUM is used rather than a spilled comparison precisely because neither page says whether an aggregate result carries a header row; SUM ignores a leading text cell either way. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED. The reference's order by example is `order by dept, salary desc` and its limit example is `limit 100`; the clause order used here, order by before limit, is the order the reference's own clause table mandates ("The order of the clauses must be as follows": select, where, group by, pivot, order by, limit, offset, label, format, options). Salaries descending run 1000, 800, 600, 500, 400, 350, so the first two are John and Mike. NOTE THAT `asc` IS NEVER SHOWN in the reference's order by section and no default direction is stated, which is why only the explicit `desc` form is asserted. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED from the one sentence that fixes the interaction: "The offset clause is used to skip a given number of first rows. If a limit clause is used, offset is applied first: for example, limit 15 offset 30 returns rows 31 through 45." Skipping one row of the descending salary order and taking two gives Mike (800) and Sally (600). ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.

DERIVED. The reference defines contains as "A substring match. whole contains part is true if part is anywhere within whole", and its own example spells out the case rule: "where name contains 'John'" matches 'John', 'John Adams', 'Long John Silver' but NOT 'john adams'. Of the six names, Dave, Sally and Dana contain a lowercase 'a'; John, Ben and Mike do not -- and Dana is the case that matters, since an uppercase-insensitive match would also pull in nothing extra here but a case-FOLDING one would not change the answer, whereas 'A' as the pattern would return only Dave and Dana's neighbours. The three are returned in source order. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.

THE TWO PAGES DISAGREE HERE AND THIS CASE EXECUTES THE ONE THAT IS SPECIFIC TO SHEETS. The query language reference says identifiers in a spreadsheet are "always letters" and the string `Col1` appears nowhere on it. QUERY's own function page says, in its Examples section, "QUERY can accept either \"Col\" notation or \"A, B\" notation", and its embedded example sheet runs `select Col1 where Col2 = 'Eng'` against a sheet range and returns John, Dave, Sally -- the same three this case counts. Neither page says when the Col form becomes REQUIRED rather than merely accepted, so this corpus asserts only that it is accepted and returns the same three rows as the letter form two cases above -- which are also the three names Google's own embedded sheet prints for this exact query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.