The consumer database catalog

Prefix: sql_.

What the consumer’s database declares, read through the generated jOOQ model: schemas, tables, columns, keys, constraints, indexes and callables. These rows are the ground that written table and column references are checked against. A few rows also transcribe what the generated model states about itself, because that model ships as one unit with the catalog it was generated from.

Where to start

sql_table: A table exists in the consumer’s catalog.
sql_column: A column exists on a table.
sql_referential_constraint: A foreign key references a constraint, the foreign-key-only extension of sql_constraint.

How this family meets the others

The normalization crossings declared for this family: rules by which a name written in one family’s vocabulary is matched against another’s census. Declared rows rather than a closed set, so a crossing nobody has declared does not appear here.

Declared crossings

intent_argmapping_key_column_candidate (graphitron_ spellings against the sql_ census): An argMapping path segment meets column names case-insensitively along the binding walk.
intent_column_match_claim (graphql_ spellings against the sql_ census): A field’s own name meets the columns of the table its site navigates to, case-insensitively, with no directive involved.
intent_field_reference_step_hop (graphitron_ spellings against the sql_ census): A written key reference meets the constraint census case-insensitively under the resolver’s namespace precedence: a qualifier binds hard, the SQL constraint name answers first, and the generated Keys-class constant is eligible only where no SQL constraint answers the name.
intent_spelled_table (graphitron_ spellings against the sql_ census): A written table reference meets the catalog census by case-insensitive match on pre-normalized spelling columns, one row per candidate.

Declared key edges

store_: 3 foreign keys from this family’s rows into that one.

Why the name is right

What the consumer’s database declares, read through jOOQ’s generated model, plus what that generated model states about the catalog it was generated from. Not jooq_: naming a family for its reader is what this name replaces, because jOOQ defines neither table nor column nor foreign key. The second clause is the narrower residency the generated-model facts earn, sql_table.class_fqn and the node-identity metadata a generated table class publishes: the corpus is one generated package, refreshed as one unit by one walk, and a prefix boundary drawn through the middle of that unit would buy a tidier charter at the price of a family that no longer matches a refresh.

sql_column

A column exists on a table. The SQL name is the coordinate, which is what the schema’s directives spell; the jOOQ name rides along because the LSP surface is Java-name-centric. A column carries two types, not one: the SQL type the database declares and the Java type jOOQ binds it to. Both are facts about the column and neither derives from the other by any rule the store could apply, since the mapping is the generator’s configured binding.

Primary key: (source_name, table_schema, table_name, column_name). Foreign key: (source_name, table_schema, table_name) references sql_table (source_name, table_schema, table_name).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name
column_name (CHARACTER VARYING, not null): SQL column name
ordinal (INTEGER, not null): column position in the table definition, read from Table.fields() rather than from the reflective field walk, whose order is unspecified
jooq_name (CHARACTER VARYING, not null): the generated jOOQ Java field name; the one column here written in the reader’s vocabulary rather than SQL’s
sql_type (CHARACTER VARYING, not null): the column’s SQL type as jOOQ reports it
binding_type (CHARACTER VARYING, not null): the fully qualified Java type jOOQ binds the column to, as Field.getType() reports it; read off the live Field during the catalog walk and unrecoverable afterwards, since nothing outside the codegen classpath can resolve a configured binding. Hover renders it beside the SQL type, which is why a column needs both and why keeping only one of them capped what the editor could say about a column.
nullable (BOOLEAN, not null): whether the column admits NULL
description (CHARACTER VARYING, nullable): the database comment on the column, when present
column_name_upper (CHARACTER VARYING, nullable): the upper-cased form of the column beside it, for the case-insensitive match against an authored column reference or the field name standing in for one. Generated, so nothing writes it and nothing can. Fold only where an authored spelling meets a catalog name. Two values of one family are compared exactly, and a comparison that does want a fold on both sides reaches this column by joining sql_column on its key rather than by having it forwarded through a derived view. intent_name_matched_key_pair is the worked example of that second sentence: both of its column names are catalog values, so it reaches a key column’s fold through the foreign key sql_constraint_column already declares here
jooq_name_upper (CHARACTER VARYING, nullable): the upper-cased form of the column beside it, for the case-insensitive match against an authored column reference or the field name standing in for one, which is the tier tried before the SQL name. Generated, so nothing writes it and nothing can. Fold only where an authored spelling meets a catalog name. Two values of one family are compared exactly, and a comparison that does want a fold on both sides reaches this column by joining sql_column on its key rather than by having it forwarded through a derived view

sql_constraint

A named constraint exists on a table. The supertype: one row per constraint whatever its form, discriminated by constraint_type as the standard’s TABLE_CONSTRAINTS is. Filtered to what jOOQ’s generated model carries: PRIMARY KEY, UNIQUE and FOREIGN KEY. CHECK, NOT NULL and deferrability are absent, and arrive as further type values rather than as new relations.

Primary key: (source_name, table_schema, table_name, constraint_name). Foreign key: (source_name, table_schema, table_name) references sql_table (source_name, table_schema, table_name). Check: "CONSTRAINT_TYPE" IN('PRIMARY KEY', 'UNIQUE', 'FOREIGN KEY').

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name
constraint_name (CHARACTER VARYING, not null): SQL constraint name
constraint_type (CHARACTER VARYING, not null): the standard’s TABLE_CONSTRAINTS vocabulary; the domain is closed over what the catalog walk reads, so a violation is a capture bug
jooq_name (CHARACTER VARYING, nullable): the generated Keys-class constant name for this constraint, which is what an author types in @reference(key:). Resolved by reference identity over the Keys class’s fields rather than by any formula over the constraint name, so a name colliding across schemas cannot mis-resolve; that resolution needs the live key on the codegen classpath and is unrecoverable afterwards. Null when the constraint resolves to no constant, which is a fact and not a failure: a generated model need not carry a Keys class, and a key with no constant is one nobody can name. Nullable where sql_table.jooq_name and sql_column.jooq_name are not, because a table and a column always have a generated Java name and a constraint need not.
key_position (INTEGER, nullable): where this constraint sits in the table’s uniqueness enumeration, jOOQ’s Table.getKeys() order with the primary key folded in, counting from zero. Captured rather than derived because the order is the generated model’s and nothing in the constraint’s own name or columns recovers it. It exists because a consumer picking one row-identifying key out of several has to pick the one the generator picks, and the generator walks this enumeration; without the position a relation ranking candidate keys would have to invent a tiebreaker among unique keys, and an invented precedence that happens to agree today is the kind of second answer that diverges silently later. Null on a FOREIGN KEY row, which is not in this enumeration at all: absence here means the constraint identifies no row rather than that its position is unknown.
table_schema_upper (CHARACTER VARYING, nullable): the upper-cased form of the column beside it, for the case-insensitive match against the namespace half of an authored key reference, which names the schema of the table holding the constraint rather than any schema of the constraint’s own. Generated, so nothing writes it and nothing can. Fold only where an authored spelling meets a catalog name. Two values of one family are compared exactly, and a comparison that does want a fold on both sides reaches this column by joining sql_constraint on its key rather than by having it forwarded through a derived view
constraint_name_upper (CHARACTER VARYING, nullable): the upper-cased form of the column beside it, for the case-insensitive match against the name half of an authored key reference. Generated, so nothing writes it and nothing can. Fold only where an authored spelling meets a catalog name. Two values of one family are compared exactly, and a comparison that does want a fold on both sides reaches this column by joining sql_constraint on its key rather than by having it forwarded through a derived view
jooq_name_upper (CHARACTER VARYING, nullable): the upper-cased form of the column beside it, for the case-insensitive match against the name half of an authored key reference, eligible only where no SQL constraint name answers it. NULL where jooq_name is, which is the constraint that resolves to no constant and therefore matches no reference. Generated, so nothing writes it and nothing can. Fold only where an authored spelling meets a catalog name. Two values of one family are compared exactly, and a comparison that does want a fold on both sides reaches this column by joining sql_constraint on its key rather than by having it forwarded through a derived view

sql_constraint_column

An ordered column of a constraint: the key columns of a primary key or a unique constraint, and the referencing columns of a foreign key, in one relation for all three forms as KEY_COLUMN_USAGE does. A foreign key’s target columns are not here; they are the referenced constraint’s own rows, matched on position.

Primary key: (source_name, table_schema, table_name, constraint_name, position). Foreign key: (source_name, table_schema, table_name, constraint_name) references sql_constraint (source_name, table_schema, table_name, constraint_name). Foreign key: (source_name, table_schema, table_name, column_name) references sql_column (source_name, table_schema, table_name, column_name).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name
constraint_name (CHARACTER VARYING, not null): SQL constraint name
position (INTEGER, not null): 0-based position in the constraint’s column list
column_name (CHARACTER VARYING, not null): SQL column name

sql_index

An index exists on a table (@order(index:) and @index resolve against it). Filtered: jOOQ’s Table.getIndexes() excludes the indexes backing a primary key or unique constraint, so those are absent here and present in sql_constraint instead. @order(index:) naming a primary key’s index therefore resolves against a documented absence rather than an apparent one.

Primary key: (source_name, table_schema, table_name, index_name). Foreign key: (source_name, table_schema, table_name) references sql_table (source_name, table_schema, table_name).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name
index_name (CHARACTER VARYING, not null): SQL index name

sql_index_column

An ordered column of an index.

Primary key: (source_name, table_schema, table_name, index_name, position). Foreign key: (source_name, table_schema, table_name, index_name) references sql_index (source_name, table_schema, table_name, index_name).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name
index_name (CHARACTER VARYING, not null): SQL index name
position (INTEGER, not null): 0-based position in the index’s column list
column_name (CHARACTER VARYING, not null): SQL column name

sql_node_key_column

An ordered entry of the key-columns constant, as stated. Deliberately no foreign key to sql_column: the constant spells a column by name and may spell one the table does not have, which is exactly the state worth recording, and the schema’s own rule puts a foreign key only where the walk writes the child while standing on the parent, never on a reference an author spells by name. The crawler stands on the table. Whether an entry resolves is intent_node_metadata_defect’s question.

Primary key: (source_name, table_schema, table_name, position). Foreign key: (source_name, table_schema, table_name) references sql_node_metadata (source_name, table_schema, table_name).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name
position (INTEGER, not null): 0-based index in the stated array, recorded rather than reconstructed: the encoded identity depends on the declared order, so a reader that recovered the order from the table’s columns or from a key would encode different ids than the ones already issued. Dense from zero within a parent, and present only under a FIELD_ARRAY parent, both gated
column_name (CHARACTER VARYING, nullable): the name the entry states, as jOOQ reports it for the field; NULL exactly when the array entry itself is null, which is a stated fact about the entry rather than an absence of one. Resolution against the table’s own columns is the derivation’s business, and it matches the reading side: case-insensitively, against the generated Java name or the SQL name

sql_node_metadata

A generated jOOQ table class states node-identity metadata: the two static constants Sikt’s KjerneJooqGenerator emits on a table it treats as a node, transcribed as stated rather than as validated. A row exists exactly when the class declares either constant, so a table with no row publishes neither, and a class declaring only half the pair is a row with the other half’s ABSENT form rather than the silence the live reflection probe folds it into. Whether what the class stated is well-formed is not asked here: that is intent_node_metadata_defect, a derivation over these rows and sql_column, which is what keeps the crawler’s job transcription. Under the sql_ family because the constants ride on the same generated package sql_table partitions on, refreshed in the same clearing round by the same walk, and sql_table.class_fqn already commits this family to facts about the generated classes; a family boundary here would cut one refresh unit in half.

Primary key: (source_name, table_schema, table_name). Foreign key: (source_name, table_schema, table_name) references sql_table (source_name, table_schema, table_name). Check: "TYPE_ID_FORM" IN('STRING', 'NULL', 'OTHER', 'ABSENT'). Check: "KEY_COLUMNS_FORM" IN('FIELD_ARRAY', 'NULL', 'OTHER', 'ABSENT'). Check: ("TYPE_ID" IS NOT NULL) = ("TYPE_ID_FORM" = 'STRING'). Check: ("TYPE_ID_CLASS" IS NOT NULL) = ("TYPE_ID_FORM" = 'OTHER'). Check: ("KEY_COLUMNS_CLASS" IS NOT NULL) = ("KEY_COLUMNS_FORM" = 'OTHER'). Check: ("TYPE_ID_FORM" <> 'ABSENT') OR ("KEY_COLUMNS_FORM" <> 'ABSENT').

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name. With the two columns above this is sql_table’s full key: the metadata is a property of the table rather than of the class, which is why the key is the table’s and not a class name
type_id_form (CHARACTER VARYING, not null): what the type-id constant stated, in a closed taxonomy the reading side’s own discrimination fixes: STRING when it held a String, NULL when it held null, OTHER when it held anything else, ABSENT when the class declares no such constant. The empty string is STRING like any other, its emptiness being a judgement the derivation makes rather than a shape capture recognises
type_id (CHARACTER VARYING, nullable): the stated value, exactly when type_id_form is STRING, empty string included; NULL otherwise, which the form column tells apart from a stated null
type_id_class (CHARACTER VARYING, nullable): the stated value’s runtime class, fully qualified, exactly when type_id_form is OTHER; NULL otherwise. The class name and deliberately not a rendering of the value: an arbitrary object’s toString may carry an identity hash, and a column that varied between two reads of one classpath would fail the warm-and-cold agreement sweep this relation sits under
key_columns_form (CHARACTER VARYING, not null): what the key-columns constant stated, on the same terms as type_id_form: FIELD_ARRAY when it held an array of jOOQ fields, NULL when it held null, OTHER when it held anything else, ABSENT when the class declares no such constant. Child rows exist exactly under FIELD_ARRAY, so an empty array is that form with no children rather than a flag of its own
key_columns_class (CHARACTER VARYING, nullable): the stated value’s runtime class, fully qualified, exactly when key_columns_form is OTHER; NULL otherwise, on the same determinism ground as type_id_class

sql_primary_key

Table T’s primary key is constraint C. Keyed by the table, because a table has at most one, which is what makes the cardinality structural instead of a gate query over a flag.

Primary key: (source_name, table_schema, table_name). Foreign key: (source_name, table_schema, table_name, constraint_name) references sql_constraint (source_name, table_schema, table_name, constraint_name).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name
constraint_name (CHARACTER VARYING, not null): the name of the PRIMARY KEY constraint in sql_constraint

sql_referential_constraint

A foreign key references a constraint, the foreign-key-only extension of sql_constraint. Referencing the constraint rather than the table is what SQL declares; the target columns are that constraint’s own sql_constraint_column rows matched on position, which is how both Oracle and the standard resolve them and is guaranteed by SQL semantics, never copied onto the referencing row. Implicit-path inference ("exactly one FK between these two tables") is a derivation over this relation, not a captured fact.

Primary key: (source_name, table_schema, table_name, constraint_name). Foreign key: (source_name, table_schema, table_name, constraint_name) references sql_constraint (source_name, table_schema, table_name, constraint_name). Foreign key: (referenced_source_name, referenced_schema, referenced_table, referenced_constraint_name) references sql_constraint (source_name, table_schema, table_name, constraint_name).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): schema of the declaring table
table_name (CHARACTER VARYING, not null): the declaring (source) table
constraint_name (CHARACTER VARYING, not null): SQL constraint name
referenced_source_name (CHARACTER VARYING, not null): the referenced constraint’s own generated-package source: equal to source_name for the ordinary in-package reference, different exactly when a foreign key crosses schemas that codegen wrote into different packages, which the multi-schema layout produces. Part of the composite reference, since the constraint’s key leads with its source
referenced_schema (CHARACTER VARYING, not null): schema of the referenced constraint’s table; part of the composite reference, not a denormalisation
referenced_table (CHARACTER VARYING, not null): the referenced constraint’s table
referenced_constraint_name (CHARACTER VARYING, not null): the referenced constraint’s name

sql_routine

A callable exists in the consumer’s catalog. Its own subject rather than columns on sql_table, on the rule that names this family: the standard the family is named for separates ROUTINES from TABLES, and a routine’s parameters are a fact about the callable, never about a result. The population is what makes that more than pedantry. A routine with no RETURNS TABLE form has a callable and no table at all, so parameters hung off sql_table would have nowhere to go the moment the walk reads one. This takes sql_constraint’s shape for the same reason: a supertype discriminated by type, with the forms an iteration does not yet read arriving as further routine_type values rather than as a reshaping. Today the walk reads jOOQ’s table census, and a table-valued function is the one routine form that appears in it, so every row here is currently a function that also has a sql_table row; whether a routine is table-valued is that join (a FUNCTION-typed sql_table row at the same coordinate), not a column here. The key is inherited from sql_table’s and carries its one hole with it: an overload set sharing a SQL name collides in both relations, jOOQ distinguishing overloads only by generated class name.

Primary key: (source_name, table_schema, routine_name). Foreign key: (source_name) references store_source (source_name). Foreign key: (source_name, table_schema) references sql_schema (source_name, table_schema).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the routine lives in
routine_name (CHARACTER VARYING, not null): SQL routine name; for a table-valued function this is also its sql_table row’s table_name, the two being one database object read two ways
routine_type (CHARACTER VARYING, not null): the standard’s ROUTINE_TYPE vocabulary: FUNCTION or PROCEDURE. Single-valued today, every captured routine reaching the store through the table census and therefore being a function; it is the discriminator that lets the other form arrive without reshaping, which is the whole argument for a supertype relation
routines_class_fqn (CHARACTER VARYING, nullable): the fully qualified name of the generated Routines class carrying this routine’s call surface, or NULL when the generated model exposes none. Captured beside the method name because the parameters below are a fact about one method: jOOQ generates several forms per routine (a Configuration-first execute form, a value-parameter form, a Field-expression form), and a parameter list that did not name its method would not say which one it described. NULL here and on the method name is also what distinguishes a routine with no parameters from one whose call surface the generated model does not expose, the two being the same zero rows in sql_routine_parameter otherwise.
routines_method_name (CHARACTER VARYING, nullable): the Routines-class method the parameters below describe: the value-parameter form, the one an emitted FROM clause calls. NULL exactly when routines_class_fqn is

sql_routine_parameter

An ordered IN parameter of a routine’s call surface. Under a family written in SQL’s vocabulary this relation carries none of it, and that is a finding rather than an omission: for a table-valued function jOOQ generates no Routine object at all, only the result table class and the Routines convenience method, so the database’s own parameter names survive only as jOOQ’s camelCase transform of them and the SQL types only as anonymous bind placeholders behind a protected field on TableImpl. Both columns were left out rather than shipped always-null or reached for through a field another module never opened.

Primary key: (source_name, table_schema, routine_name, position). Foreign key: (source_name, table_schema, routine_name) references sql_routine (source_name, table_schema, routine_name).

Columns

source_name (CHARACTER VARYING, not null): the owning partition’s generated-package source, as on sql_table; the key’s leading dimension
table_schema (CHARACTER VARYING, not null): SQL schema the routine lives in
routine_name (CHARACTER VARYING, not null): SQL routine name
position (INTEGER, not null): 0-based position in the call surface’s parameter list, which is the routine’s declaration order
jooq_name (CHARACTER VARYING, not null): the generated method parameter’s Java name, read reflectively; jOOQ’s camelCase transform of the database’s own parameter name, and the closest this relation gets to it. Reflection reports it only when the consumer compiled their jOOQ output with -parameters, and reports arg0, arg1 otherwise. The generator already depends on that flag, matching @routine(argMapping:) against these names, so recording the name makes an existing dependency visible rather than creating one.
binding_type (CHARACTER VARYING, not null): the fully qualified Java type the generated method takes at this position, as on sql_column.binding_type. Unlike a column, a parameter carries no declared SQL type beside it; the relation’s own comment says why

sql_schema

A schema exists in the consumer’s catalog, and carries the generated artifacts that belong to the schema rather than to any one of its tables. It exists because those classes are per schema: hanging a name off sql_table would repeat one value across every table in the schema, which is the repeating group the projection era shipped. Two such artifacts so far, the Keys class and the Tables class, and both are here for the same reason rather than the second being an afterthought: each is one class serving a whole schema, and each is reachable only by loading it off the codegen classpath. Written for every schema the catalog census touches, so a table’s schema is always present.

Primary key: (source_name, table_schema). Foreign key: (source_name) references store_source (source_name).

Columns

source_name (CHARACTER VARYING, not null): the generated package the schema lives in; the partition this row belongs to and the key’s leading dimension, as on sql_table
table_schema (CHARACTER VARYING, not null): SQL schema name; empty string when the generated model declares no schema for its tables, which is the same fallback sql_table applies
keys_class_fqn (CHARACTER VARYING, nullable): the fully qualified name of the generated Keys class holding this schema’s key constants, resolved by loading it off the codegen classpath rather than by concatenating a configured package with ".Keys". The guess and the fact diverge under multi-schema layouts, where each schema gets its own Keys class in its own package. Null when the generated model carries no Keys class for the schema, which is a fact: a schema with no keys has no constants to name. Goto-definition on @reference(key:) lands in this class, so it is a join key rather than a completion nicety.
tables_class_fqn (CHARACTER VARYING, nullable): the fully qualified name of the generated Tables class holding this schema’s table constants, on exactly the terms the column beside it states: resolved by loading it off the codegen classpath rather than by concatenating a configured package with ".Tables", the guess and the fact diverging under multi-schema layouts where each schema gets its own Tables class in its own package. Null when the generated model carries no Tables class for the schema, which is a fact rather than a gap. This is the column that lets a reader assemble a table reference without a live catalog: every other part of one is already here or on sql_table, and the constants class was the single piece reachable only through the codegen loader, so its absence was what kept table references a walk-side construction

sql_table

A table exists in the consumer’s catalog. Every table jOOQ’s generated model declares, across every schema it declares; ambiguity of an unqualified @table(name:) is a resolution question and therefore derivation, so capture just records them all.

Primary key: (source_name, table_schema, table_name). Foreign key: (source_name) references store_source (source_name). Foreign key: (source_name, table_schema) references sql_schema (source_name, table_schema).

Columns

source_name (CHARACTER VARYING, not null): the generated package the table’s schema lives in; the partition this row belongs to and the key’s leading dimension, so two modules' catalogs carrying one (schema, table) coordinate coexist instead of the second build clobbering the first. The package rather than the classpath entry it was loaded from, because one jar carries every schema a codegen run produced and invalidating the jar would discard them all, while the package is the granularity codegen actually rewrites. Schemas flattened into one package (jOOQ’s outputSchemaToDefault) share a source, which is correct: they are regenerated together
table_schema (CHARACTER VARYING, not null): SQL schema the table lives in
table_name (CHARACTER VARYING, not null): SQL table name
table_type (CHARACTER VARYING, not null): what kind of table-like object this is, in jOOQ’s TableOptions.TableType vocabulary: TABLE, TEMPORARY, VIEW, MATERIALIZED_VIEW, FUNCTION, EXPRESSION or UNKNOWN. A property of the object every catalog states and this family recorded none of, so the store could not tell a base table from a view. FUNCTION is the value that carries weight today: it marks a table-valued function’s result, which has no primary key and no foreign keys by construction, and that one property is what every carve-out on a function-backed field turns on. A reader asking whether a name is table-valued asks this column rather than reaching back into the live catalog. The callable behind a FUNCTION row is its own subject in sql_routine, joined on the shared (source, schema, name).
jooq_name (CHARACTER VARYING, not null): the generated jOOQ Java field name for the table; under a family named for SQL this is the one foreign column, so the prefix marks it rather than leaving a reader to infer it
class_fqn (CHARACTER VARYING, not null): the fully qualified name of the generated jOOQ table class, read off the live Table during the catalog walk. Per table, unlike the Keys class name, which is per schema and lives on sql_schema. Goto-definition on @table(name:) and @field(name:) lands in this class, and jvm_class cannot supply it because that family deliberately excludes the generated jOOQ package, so this is the join key that reaches generated sources at all.
record_class_fqn (CHARACTER VARYING, not null): the fully qualified name of the record class jOOQ binds this table’s rows to, read off the live Table during the catalog walk. A different fact from class_fqn beside it, and neither spells the other: that is the generated table class an author navigates to, this is the row type a producer method hands back, and the naming relation between them is jOOQ codegen configuration rather than anything the store may assume. Always present, a table always having a row type; a table jOOQ generated no record class for reports org.jooq.Record, which is the catalog’s own answer and stands as written, a reader that wants only generated records comparing against that name rather than reading a NULL. The classpath census cannot supply this, excluding the generated jOOQ package by design, so it is how a type bound to a table reaches a class name at all.
description (CHARACTER VARYING, nullable): the database comment on the table, when present
table_schema_upper (CHARACTER VARYING, nullable): the upper-cased form of the column beside it, for the case-insensitive match against the namespace half of an authored table or routine reference. Generated, so nothing writes it and nothing can. Fold only where an authored spelling meets a catalog name. Two values of one family are compared exactly, and a comparison that does want a fold on both sides reaches this column by joining sql_table on its key rather than by having it forwarded through a derived view
table_name_upper (CHARACTER VARYING, nullable): the upper-cased form of the column beside it, for the case-insensitive match against the name half of an authored table or routine reference, and against graphitron_table.type_name_upper where the name argument was omitted. Generated, so nothing writes it and nothing can. Fold only where an authored spelling meets a catalog name. Two values of one family are compared exactly, and a comparison that does want a fold on both sides reaches this column by joining sql_table on its key rather than by having it forwarded through a derived view. intent_field_reference_discovery is the worked example of that second sentence: both of its table names are catalog values, so it joins this relation twice on its key to compare them here

← Schema index