Module names 

Names the schema does not carry.

Almost everything in the generated API is derived: a table’s own name gives the root fields, a foreign key gives a relationship, a function gives a computed field. Hasura derives none of it. Every one of those names is written down in metadata by a person – add_computed_field says the function is fetch_articles_plain and the field is get_articles, create_array_relationship says the relationship is posts – and reflection cannot recover a name nobody wrote down.

That is the single largest remaining divergence from Hasura, and it does not shrink by implementing anything. Around 25 cases in Hasura’s own corpus fail on it across four groups, every one of them by answering correctly under a different name.

So names can be given – and, since a permission is the same kind of thing, permissions too. Both are decisions a person wrote into metadata that no schema remembers. This is still a lookup table rather than a metadata model: it tracks no tables, offers no API to change it, and a table absent from it is exposed exactly as before.

{
  "public.author": {
    "name": "Authors",
    "roots": { "select_by_pk": "Author" },
    "columns": { "id": "AuthorId" },
    "relationships": { "article_author_id_fkey": "posts" },
    "computed_fields": { "automatic_comment_in_db_upper_name": "upper_name" },
    "permissions": {
      "user": {
        "select": {
          "columns": ["id", "name"],
          "filter": { "id": "X-Hasura-User-Id" },
          "limit": 10
        }
      }
    }
  }
}

The module is called names because names came first, and the document’s variable keeps both spellings for the same reason. What it holds is now wider than that.

Relationships and computed fields are keyed by the thing the database actually has – a constraint name, or a function name – rather than by the name being replaced. A derived name is what this exists to change, so keying by it would mean writing down the answer to ask the question; and where two foreign keys point at one table the derived names collide, which is one of the cases this is for.

Columns are keyed by the column, which is the same rule: the column is what the database has. It is also the entry that reaches furthest – a renamed column is a name in the schema and in nothing else, so every path from a request to SQL translates it back.

Structs

Comments

Descriptions given to one table and the things on it.

DeclaredRelationship

One relationship metadata declares, and how it is reached.

DeletePermission

Which rows a role may delete.

FederationConfig

Apollo Federation settings for one table.

FunctionNames

What metadata says about one function, beyond what the catalogue knows.

InsertPermission

What a role may write, and what the result has to satisfy.

NameOverrides

Every name given, keyed by schema.table.

RolePermissions

What one role may do with one table.

SelectPermission

Which rows a role may read, and which of their columns.

TableNames

The names given to one table.

UpdatePermission

Which rows a role may change, which columns of them, and what the result has to satisfy.

Enums

ColumnSet

The columns a permission covers.

ColumnTypeOverride

A GraphQL scalar a database column may be exposed as.