Try Opteryx

Virtual Datasets

Opteryx provides a small number of relations that are computed when queried rather than read from storage. They are named with a leading $, which is reserved for the engine — a name you create can never collide with one.

They fall into two groups, and the difference matters: some are ordinary relations you can SELECT from and join, and some exist only to back a SHOW statement.

Queryable by name

These behave like any other relation — you can project, filter, join and aggregate them.

Dataset Contents
$planets Sample data: 9 rows, 20 columns of planetary facts. Also temporal — see time travel, where querying before 1781 returns fewer rows
$no_table A single row with one column, used as the source for a SELECT with no FROM. Rarely written explicitly 
SELECT name, gravity
  FROM $planets
 WHERE number_of_moons > 1;

Reachable only through a SHOW statement

Each of these is deliberately not addressable by name. Each has exactly one surface, so the statement and the relation cannot drift into disagreeing:

Relation Its only surface Columns
$variables SHOW VARIABLES name, value, type, owner, visibility
$user SHOW USER attribute, value, type
$grants SHOW GRANTS pattern, role, actions

Querying one by name is refused, and the error names the statement to use instead:

SELECT * FROM $grants;
-- '$grants' cannot be queried directly; use `SHOW GRANTS`.

The cost of that rule is real and taken deliberately: because no SHOW form can appear in a FROM clause, these cannot be joined or filtered at the source. Filter the returned rows client-side instead.

Notes

  • $-prefixed names are reserved for the engine. See Reserved Words for the identifier rules.
  • The set of virtual datasets is not a stable API — treat $planets as sample data for learning and testing, not as a fixture to build on.