Exact, bounded-size snapshots of stored SQL catalog inputs.
Exact capture is accelerated by checked runtime dependency tokens. Cached bases retain detached values only, bounded to eight entries and 32MiB of structural weight (not exact JVM heap). Strict schemas use attribute-index ranges; read schemas require an AEVT scan to discover undeclared catalog attributes. The latter also visits user data.
Exact, bounded-size snapshots of stored SQL catalog inputs. Exact capture is accelerated by checked runtime dependency tokens. Cached bases retain detached values only, bounded to eight entries and 32MiB of structural weight (not exact JVM heap). Strict schemas use attribute-index ranges; read schemas require an AEVT scan to discover undeclared catalog attributes. The latter also visits user data.
Optional caller-owned IdentityHashMap, bound for one statement only. At most eight DB identities are retained. Mutable catalog captures bypass this cache; cross-statement reuse requires checked dependency tokens.
Optional caller-owned IdentityHashMap, bound for one statement only. At most eight DB identities are retained. Mutable catalog captures bypass this cache; cross-statement reuse requires checked dependency tokens.
(capture db)(capture db options)Detached exact schema/catalog comparison value; nil DB returns nil. See default-limits for structural bounds. Read schemas visit all AEVT datoms; strict schemas use catalog attribute ranges. Temporal/filter views are preserved. Eligible tracked snapshots share a bounded detached-basis cache. Mutable dates/arrays bypass both caches. Optional capture-cache reuses identical DB objects with equal limits/configuration/checked tokens and must be scoped by the caller to one statement.
Detached exact schema/catalog comparison value; nil DB returns nil. See default-limits for structural bounds. Read schemas visit all AEVT datoms; strict schemas use catalog attribute ranges. Temporal/filter views are preserved. Eligible tracked snapshots share a bounded detached-basis cache. Mutable dates/arrays bypass both caches. Optional *capture-cache* reuses identical DB objects with equal limits/configuration/checked tokens and must be scoped by the caller to one statement.
(catalog-attribute? attr)Stored catalog namespaces, including future attributes in those namespaces. Sequence values are intentionally not catalog definitions, and neither is the OID allocator's counter (see tracking-selector). Ident datoms bind logical schema names to entity IDs, including schema entity ordering.
Stored catalog namespaces, including future attributes in those namespaces. Sequence values are intentionally not catalog definitions, and neither is the OID allocator's counter (see tracking-selector). Ident datoms bind logical schema names to entity IDs, including schema entity ordering.
(compatible? basis db)matches?, widened by only-new-relations?: a catalog that merely
GAINED relations cannot have changed what an already-lowered statement
reads, so it is not a reason to abort that statement's write.
`matches?`, widened by `only-new-relations?`: a catalog that merely GAINED relations cannot have changed what an already-lowered statement reads, so it is not a reason to abort that statement's write.
Structural accounting limits, not an exact JVM heap guarantee.
Structural accounting limits, not an exact JVM heap guarantee.
(freeze-projection value)Detach a metadata reader result under default structural limits. Token eligibility requires exclusively recognized immutable values; mutable values are detached but cannot certify subsequent token reuse.
Detach a metadata reader result under default structural limits. Token eligibility requires exclusively recognized immutable values; mutable values are detached but cannot certify subsequent token reuse.
(matches? basis db)Compare using a checked unchanged dependency token when eligible; otherwise compare exact detached metadata. Never trust hashes, transaction counters, server invalidation generations, or schema identity alone.
Compare using a checked unchanged dependency token when eligible; otherwise compare exact detached metadata. Never trust hashes, transaction counters, server invalidation generations, or schema identity alone.
(only-new-relations? expected current)Whether current differs from expected ONLY by relations that did not
exist when expected was captured.
The guard this serves protects a statement lowered against expected
from being written against a catalog that changed under it. Exact
equality answers that conservatively but too bluntly: another session
running CREATE TABLE other invalidated every open transaction, even
though nothing those transactions could have read had changed. So the
difference is examined instead, and admitted only in the one shape
that cannot affect an already-lowered statement:
ALTER TABLE … ADD COLUMN therefore does NOT qualify -- it adds an
attribute in an EXISTING relation's namespace, which a lowered
statement may have to see (a default, a constraint) -- and neither
does a DROP, a RENAME or a type change, which modify or remove what
the capture held.
Whether `current` differs from `expected` ONLY by relations that did not
exist when `expected` was captured.
The guard this serves protects a statement lowered against `expected`
from being written against a catalog that changed under it. Exact
equality answers that conservatively but too bluntly: another session
running `CREATE TABLE other` invalidated every open transaction, even
though nothing those transactions could have read had changed. So the
difference is examined instead, and admitted only in the one shape
that cannot affect an already-lowered statement:
- nothing the expected capture held may be MISSING or CHANGED, in
the frozen schema or in the catalog rows; and
- every added row must belong to an entity the expected capture did
not have, naming relations it did not know.
`ALTER TABLE … ADD COLUMN` therefore does NOT qualify -- it adds an
attribute in an EXISTING relation's namespace, which a lowered
statement may have to see (a default, a constraint) -- and neither
does a DROP, a RENAME or a type change, which modify or remove what
the capture held.(temp-object-name? v)Does this value name a session-private catalog object? A temp table's
storage name is __dh_pg_temp_<session>_<name>, carried either as a
string or as the namespace of an attribute keyword.
Does this value name a session-private catalog object? A temp table's storage name is `__dh_pg_temp_<session>_<name>`, carried either as a string or as the namespace of an attribute keyword.
The namespace prefix of a session-private (temporary) catalog object. PostgreSQL keeps another backend's temp schema invisible; here temp objects are ordinary global catalog rows, so the basis has to hide them itself -- otherwise one session's temp DDL, including the cleanup at disconnect, invalidates every other session's statement.
The namespace prefix of a session-private (temporary) catalog object. PostgreSQL keeps another backend's temp schema invisible; here temp objects are ordinary global catalog rows, so the basis has to hide them itself -- otherwise one session's temp DDL, including the cleanup at disconnect, invalidates every other session's statement.
(without-replayed-enum-markers basis markers)Normalize an expected replay basis for exact [entity label] marker adds intentionally omitted from the preceding transaction buffer. Never apply this to the writer's actual basis or to a semantic plan/cache key.
Normalize an expected replay basis for exact [entity label] marker adds intentionally omitted from the preceding transaction buffer. Never apply this to the writer's actual basis or to a semantic plan/cache key.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |