Expand description
What duckdb_functions() says about each function this engine knows.
Twenty one columns and one row per name per argument count, over the scalar and aggregate names
in crate::signature and the table functions in crate::table. It is the same kind of table
as duckdb_types(): a client reads it to find out what the engine supports, so it lists what the
engine has rather than what the pinned binary has.
§An overload here is a name and a count, not a name and a pair of types
This is the one place where rudb’s table and upstream’s are shaped differently rather than just
different lengths, and it follows from a decision crate::signature made first. That table
resolves by shape: + is one entry saying both arguments promote and the result is what they
promote to. Upstream carries an entry per pair of argument types, because it carries an
implementation per pair, so it reports 44 rows for + naming concrete types where this reports
two, one per arity.
So the types in this table are declared types. T is the type variable and means the call
decides, and every argument spelled T in one row is the same type as the others. ANY is the
weaker one and means the argument is not tied to the others, which is what count(x) takes. Both
spellings are upstream’s own, which uses T for list_extract and lag and ANY for least,
so a client that already reads this table does not have to learn a third vocabulary. A return of
ANY means the arguments decide it in a way no name can say, which is where sum is, since it
promotes and then widens an integer to the accumulator.
§Builtins are in system.main and rudb has no catalog called that
Said plainly because it is the one column here that names something that does not exist yet.
Upstream puts every builtin in system.main and system.pg_catalog and puts nothing in
memory, which is the opposite of duckdb_types(), where the types are repeated once per
catalog. Reporting memory here would break every client query that filters on the schema and
would say the functions belong to a database, which is not true of a builtin. So this says
system.main. The catalog tables have landed since and the catalog still has no system entry,
so duckdb_schemas() cannot return the name this column reports. That is #607 rather than a
thing this file can fix, because the entry has to come from the catalog and not from here.
function_oid is null for the same reason database_oid is null in duckdb_types(): upstream’s
is a counter its catalog handed out at startup and rudb has no oid space. description,
comment, examples and categories are null because rudb has no documentation strings
attached to its functions, and inventing a sentence per name here would put the documentation
somewhere nobody maintains it.
§What the table does not have yet
No window functions, because rudb has none. No macros, no pragma functions and no table macros,
for the same reason. has_side_effects is false and stability is CONSISTENT on every scalar
and aggregate row, because every function rudb has is a pure function of its arguments: there is
no random, no nextval and no now in the table yet. A volatile one arrives with a row that
says so rather than with this column quietly staying wrong, which is why it is derived from
nothing and asserted in a test.
Structs§
- Function
Entry - What one row of
duckdb_functions()says, before it is turned into values.
Constants§
- CONSISTENT
- The stability every function in this engine has, since none of them is volatile yet.
- FUNCTION_
CATALOG - The catalog builtins are reported as belonging to, which is upstream’s name for it.
- FUNCTION_
SCHEMA - The schema builtins are reported as belonging to.
Functions§
- function_
entries - Every function this engine has, sorted by name and then by how many arguments it takes.
- function_
fields - The columns
duckdb_functions()produces, which is DuckDB’s twenty one.