SQL: Behavior of standalone SELECT

[philrz]

Consider:

$ super -c "SELECT;"
error("missing")

Between the SQL standard, Postgres, and other SQL implementations, there's varying takes on how this should behave.

Details

Repro is with super commit bce1669. This was found via a query from a sqllogictest.

In Postgres, the query succeeds and returns "1 row", though I find it difficult to understand what's in the row.

$ psql postgres
psql (17.5 (Homebrew))
Type "help" for help.

postgres=# SELECT;
--
(1 row)

Others treat this as a failure, including DuckDB, ClickHouse, and MySQL.

$ duckdb
DuckDB v1.3.2 (Ossivalis) 0b83e5d2f6
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

D SELECT;
Parser Error:
SELECT clause without selection list

$ clickhouse
ClickHouse local version 25.6.2.5 (official build).

:) SELECT;

Syntax error: failed at position 7 (end of query):

SELECT;

Expected one of: ALL, DISTINCT ON, DISTINCT, TOP, not empty list of expressions, list of expressions, list of elements, expression with optional alias, element of expression with optional alias, lambda expression, CAST operator, NOT, INTERVAL, CASE, DATE, TIMESTAMP, tuple, collection of literals, array, number, literal, NULL, NULL, Bool, TRUE, FALSE, string literal, asterisk, qualified asterisk, compound identifier, identifier, COLUMNS matcher, COLUMNS, qualified COLUMNS matcher, function name, substitution, MySQL-style global variable

$ mysqlsh
MySQL Shell 9.3.0

Copyright (c) 2016, 2025, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Type '\help' or '\?' for help; '\quit' to exit.
 MySQL  SQL > \connect root@localhost
Creating a session to 'root@localhost'
Fetching global names for auto-completion... Press ^C to stop.
Your MySQL connection id is 10
Server version: 9.3.0 Homebrew
No default schema selected; type \use <schema> to set one.

 MySQL  localhost:3306 ssl  SQL > SELECT;
ERROR: 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

I have no easy way of checking the SQL standard, but if ChatGPT can be trusted, it claims that Postgres is going their own way here, as it claims that in the BNF grammar definition in the SQL-2016 standard, there is no version of <select list> that is empty.

As for SuperDB, it seems we're kind of going our own way as well, since we do parse the query as valid, but then return error("missing"), so it's a successful query showing only an error value.

$ super -version
Version: bce166968

$ super -c "SELECT;"
error("missing")

$ echo $?
0

We've often stated a goal to match Postgres behavior when in doubt, but since this is kind of a corner case with no obvious real world implications, I don't see a strong argument for any particular direction.