The consumer database catalog

One table the consumer’s catalog declares.

One column of one table the consumer’s catalog declares.

One foreign key’s reference to the constraint it resolves against.

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.

A written table reference meets the catalog census by case-insensitive match on pre-normalized spelling columns, one row per candidate.

An argMapping path segment meets column names case-insensitively along the binding walk.

A field’s own name meets the columns of the table its site navigates to, case-insensitively, with no directive involved.

4 foreign keys from this family’s rows into that one.

14 foreign keys from that family’s rows into this one.

1 foreign key from that family’s rows into this one.

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the table lives in

SQL table name

SQL column name

column position in the table definition, read from Table.fields() rather than from the reflective field walk, whose order is unspecified

the generated jOOQ Java field name; the one column here written in the reader’s vocabulary rather than SQL’s

the column’s SQL type as jOOQ reports it

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.

whether the column admits NULL

the database comment on the column, when present

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. sql_name_matched_key_column 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

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

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the table lives in

SQL table name

SQL constraint name

the standard’s TABLE_CONSTRAINTS vocabulary; the domain is closed over what the catalog walk reads, so a violation is a capture bug

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.

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.

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

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

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

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the table lives in

SQL table name

SQL constraint name

0-based position in the constraint’s column list

SQL column name

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the constraint’s own generated-package source, the first column of the sql_referential_constraint key this row is about

the schema of the table declaring the constraint, carried from the constraint rather than from either end of the hop: the declaring table is a property of the key and is the same whichever way the key is travelled

the table declaring the constraint; with the two columns above and the name beside it, the constraint this hop rides

the constraint’s SQL name; with the three columns above, a reference into sql_referential_constraint

whether the key is declared on the departure, which is what tells the two rows of one constraint apart and is the rest of the grain. True is the forward reading, departing the declaring table and arriving at what it references; false is the same key ridden against itself, which is how a parent reaches its children and is no less a hop for it

the generated-package source of the table a hop riding this key departs from, the first of the three columns naming it

the departure’s schema as the catalog spells it

the departure’s own name; with the two columns above, a table of sql_table. A fact about the database rather than about any schema that names the key: a constraint affords both of these hops whether or not an author ever writes a path through it, which is why they are written down once here instead of being derived again at every element that names the key

the generated-package source of the table a hop riding this key arrives at, the first of the three columns naming it

the arrival’s schema as the catalog spells it

the arrival’s own name; with the two columns above, a table of sql_table. The two ends swap between the row pair and nothing else does, so a reader holding one direction holds the other by the constraint

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension. A class reachable from two sources is two rows, on code_class.source_name’s terms

the fully qualified name of the enum class, as Field.getType() reports it; the value a declared parameter type is compared against, and the reason the comparison can be an equality rather than a fold: both sides are binary names nobody wrote by hand. An array-typed column contributes no row, its bound type being the array and not the element

the SQL schema declaring the database enum type this class was generated for; NULL where the class names no catalog type, which is the converter-bound Java enum the table comment describes, and NULL again where it names one that is not schema-scoped. Not a foreign key into sql_schema for the first reason: that half is not a schema the walk failed to resolve, it is a row for which no schema is the right answer

the database enum type’s own name, as the generated class reports it; NULL where the class names no catalog type, which is the wider of the two silences beside it. Carried so a reader can name the type an author would see in their database rather than only the class jOOQ generated from it

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the table lives in

SQL table name

SQL index name

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the table lives in

SQL table name

SQL index name

0-based position in the index’s column list

SQL column name

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the departing function result’s generated-package source, as on sql_table

the departing function result’s SQL schema

the departing function result’s SQL name; always a table of type FUNCTION, this rule having no subject where a foreign key could be read instead

the function result’s column of the same name, which is the one the join reads. NOT NULL: a key with an unexposed column is not stated at all, so this column never carries the absence its predecessor did

the arriving table’s catalog source

the arriving table’s SQL schema

the arriving table’s SQL name; a table with a primary key, which is what there is to match against

the arriving table’s primary-key column at that position

the arriving key column’s own ordinal, copied from sql_constraint_column where the constraint declares it rather than assigned here. A join predicate does not care in which order its equalities are conjoined, so this is not what makes the pairing correct; it is what lets a consumer build a key tuple in the key’s order without going back to the constraint for one, and what gives every consumer the same order without agreeing on a tie-break

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the table lives in

SQL table name

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

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

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the table lives in

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

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

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

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

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

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

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the table lives in

SQL table name

the name of the PRIMARY KEY constraint in sql_constraint

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

schema of the declaring table

the declaring (source) table

SQL constraint name

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

schema of the referenced constraint’s table; part of the composite reference, not a denormalisation

the referenced constraint’s table

the referenced constraint’s name

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the routine lives in

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. The key inherits sql_table’s one hole with it: an overload set sharing a SQL name collides in both relations, jOOQ distinguishing overloads only by generated class name

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

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.

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

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the owning partition’s generated-package source, as on sql_table; the key’s leading dimension

SQL schema the routine lives in

SQL routine name

0-based position in the call surface’s parameter list, which is the routine’s declaration order

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.

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: jOOQ generates no Routine object for a table-valued function, so the declared type survives only as an anonymous bind placeholder behind a protected field on TableImpl, and was left out rather than shipped always-null

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the generated package the schema lives in; the partition this row belongs to and the key’s leading dimension, as on sql_table

SQL schema name; empty string when the generated model declares no schema for its tables, which is the same fallback sql_table applies

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.

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

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

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

SQL schema the table lives in

SQL table name

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).

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

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 code_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.

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.

the database comment on the table, when present

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

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_entry.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

when the reading that produced this row ran. The reading finishes by deleting this source’s rows carrying a different instant, which are the tables, columns and keys the consumer’s database no longer has and which an upsert alone cannot find. Nullable because one writer of these relations sets nothing here, and a row with no instant is not this reading’s

the generated package the table’s schema lives in, as on sql_table; the key’s leading dimension and the refresh unit the whole sql_ family is scoped by

the table’s SQL schema, as on sql_table

the table’s SQL name, as on sql_table; with the two columns above, the table whose record class this row is about. Keyed on the table rather than on the record class, so the row is deleted with its table and no reader has to reconcile two spellings of one identity

the fully-qualified binary name of one type the record class is, a nested one spelled with the $ the JVM uses, and spelled the way the reading spells a class name so a declared parameter type compares to it exactly. Every element of the closure and not only the declared parents, the relation holding a closure for the reason its own comment gives; the record class itself is deliberately not a row, a reader asking about it holding sql_table.record_class_fqn already. Frequently not a class the reading reached and never a foreign key: jOOQ’s runtime classes are not scanned, which is what makes capturing this necessary rather than derivable

the declaring table’s generated-package source, as on sql_table; the key’s leading dimension

schema of the declaring table, the end the foreign keys sit on

the declaring table’s SQL name

the referenced table’s own generated-package source, equal to source_name for the ordinary in-package reference and different exactly where a foreign key crosses schemas codegen wrote into different packages

schema of the referenced table

the referenced table’s SQL name. The pair is ordered: the declaring end and the referenced end are not interchangeable, and a pair keyed the other way round is a different row or no row at all

how many foreign keys connect the pair in this direction; 1 where the route between the two tables is unambiguous, which is what a reader discovering a key rather than naming one tests for. Counted here rather than by each reader, because a reader that counts is a per-row aggregate over the census and this is a fact about the catalog that does not vary with who asks

when the reading that produced this row ran, on sql_referential_constraint’s terms: the reading finishes by deleting this source’s rows carrying a different instant. NOT NULL where that relation’s is nullable, this one having exactly one writer, and load-bearing rather than tidy: a pair row that outlives the foreign key it counted says 1 about a pair with none, which is the arm a discovering reader takes