Evokoa/pgGraph v1.2.0

v1.2.0: pgGraph Open-Vocabulary Relationship Types

on GitHub

pgGraph 1.2 removes the historical 254-label graph ceiling for
LLM-generated and other open-vocabulary relationship types while keeping
compact physical storage and explicit resource limits. It also makes typed
relationship tables safer to discover and adds a clean recovery path for stale
registrations. PostgreSQL 14 through 18 remain supported.

Open Relationship Types

• Relationship types now use a checked logical EdgeTypeId(u32). A graph may
  contain up to 1,000,000 distinct types, with a 1,024-byte UTF-8 limit per
  label and a 256 MiB cumulative dictionary limit.
• New v7 bases and mutable segments select one-, two-, or four-byte type
  storage, so graphs with small vocabularies retain byte-sized edge type IDs.
• Trigger-backed committed graph.apply_sync() interns valid unseen labels
  and publishes the updated dictionary without requiring a full rebuild.
• traverse, shortest paths, explicit GQL/Cypher relationship types, and
  eligible WHERE r.relationship_name = $x predicates use exact compact type
  filters. Absent types return no match; ambiguous endpoint mappings fail
  closed.
• graph.edge_types() pages the complete effective dictionary in stable ID
  order. graph.status() keeps a bounded 64-entry preview. Type-filter arrays
  are limited to 4,096 entries and 4 MiB before allocation.

Registration And Discovery

• Auto-discovery recognizes supported binary relationship tables as one edge
  mapping, including surrogate-key tables with conventional dynamic label
  columns such as relationship_name.
• Composite foreign keys, repeated endpoint columns, alternate unique-key
  references, and three-or-more-endpoint tables are left for explicit mapping
  instead of being guessed into incorrect graph edges.

Registration-Clearing Reset

• The new graph.reset(boolean) overload provides a direct recovery path for
  stale registrations. graph.reset(true) clears the selected graph's
  projection, artifacts, tables, edges, and filter registrations.
• The zero-argument graph.reset() call remains projection-only and preserves
  registrations for a rebuild.
• Neither form modifies PostgreSQL source tables or other named graphs. After
  graph.reset(true), reapply the selected graph's registrations before
  calling graph.build().
• See Stale Registration Produces PG000
  for the recovery sequence.

Upgrade, Artifacts, And Rollback

• The 1.1.0 -> 1.2.0 extension update is additive: it installs
  graph.edge_types() and graph.reset(boolean) without replacing existing
  function objects or changing their owners and explicit grants.
• Existing v6 artifacts remain readable without a blanket rebuild. New builds
  publish v7 artifacts. Rebuild when the base artifact itself must represent
  more than 254 relationship types.
• In-place downgrade is not supported. A 1.1 binary cannot read 1.2 v7
  artifacts and must not be installed over 1.2 catalogs. Rollback restores the
  pre-upgrade PostgreSQL backup with the matching 1.1.0 package, then rebuilds
  derived graph state from the restored source tables.

Validation And Performance

• Retained exact-commit evidence covers 65 Criterion cases, eight PostgreSQL
  latency cases, and Linux resource runs at 1, 4, and 8 backends.
• The 65,536-label fixture used 54.7 bytes per directed edge against a
  64-byte budget. Its measured 8-to-1 total and baseline-subtracted query PSS
  ratios were 5.86x and 6.36x against 9.0x limits.
• These measurements verify the release budgets in the recorded environment;
  they are not universal latency or memory guarantees.