Module functions 

The graph functions in SQL: which of ursa_core::catalog’s functions a query can call, how a call’s SQL arguments become a catalog Call, and the wording of every message about them.

The catalog is the single source of truth for names, parameters, defaults, accepted values and output types, shared with the Python library, so a call means the same thing in both. This module only adds SQL’s choices:

• Which functions. Every algorithm, every statistic and the neighbour aggregation. The layouts (layout_fr, layout_random, layout_circle) are left out ([in_sql]), hidden until the visualization work, as they are from the Python library’s public API. A call fails as an unknown function would, and no message or listing names them.
• Node values. The neighbour aggregation (neighbors_agg) reads one value per node. SQL gives them as a query of (id, value) rows, values => (SELECT id, age FROM people) (VALUES, a parameter only SQL has), or as an expression over the graph’s node table, attribute => age (the catalog’s attribute). Either is planned as a child of the graph node, as a traversal’s node ids are.
• No dtype. SQL has CAST; a call never narrows its own column.
• weight => is an expression over the edge table’s columns, planned by the relation planner as a column of the node’s edge plan, not a literal resolved here.
• Messages, worded for SQL: pagerank(damping =>) must be a number; got 'high'.

Enums

Literal

A literal argument as written: a (possibly signed) number, a string, a boolean or NULL.

Constants

ALGORITHMS

The multi-algorithm table function: algorithms(g, degree(), c => louvain()).

N_DROPPED_EDGES

describe’s count of the edges left out of the graph because an endpoint is not a key of its vertex table (#311). SQL’s own column: a Python graph has no vertex table, so it would always be 0 there.

URSA_FUNCTIONS

The function catalog as a table: SELECT * FROM ursa_functions().

VALUES

neighbors_agg(values => (SELECT id, value FROM ...)): the node values as a query. SQL’s alternative to the catalog’s attribute, which in SQL is an expression over the graph’s node table.

VALUES_QUERY

The form of a values => argument, for messages.

Functions

did_you_mean

The closest of candidates to name, if one is close enough to be a typo (the graph DDL’s rule, so every “did you mean” agrees).

display_call

The call as SQL would spell it, every literal parameter shown, and the weight when there is one: for EXPLAIN.

is_per_node

Whether spec returns one row per node (an algorithm), as opposed to one row for the whole graph (a statistic).

lookup

The catalog function called name, if SQL can call it.

names

The names of the graph table functions: the catalog’s, the traversals, then algorithms.

nested_signature

pagerank(damping => 0.85, ...): a call as written inside algorithms().

outputs

The columns a call to spec returns in SQL, besides id: the catalog’s, then for describe N_DROPPED_EDGES. An output’s field indexes this list; past the catalog’s own, the engine computes it (kernels).

resolve

Resolve the literal arguments of a call to spec (names already normalized; weight already taken out by the caller) to a Call.

signature

pagerank(<graph>, damping => 0.85, ...): the call with every parameter at its default, for messages.

specs

Every catalog function SQL can call, in catalog order.

sql_doc

A parameter’s one-line description, as SQL reads it.

sql_params

The parameters a SQL call can name: all but dtype, in the catalog’s order, after VALUES for a function that reads node values.

sql_type

How SQL writes a value of parameter name, of type ty: number, string, query …

sql_value

A catalog value as SQL writes it: NULL, 'out', 30, 0.85, 1e-6.

unknown_param

“pagerank() has no parameter ‘dampng’; did you mean ‘damping’? …”.