Consolidate on the index access method; auto-provision opclasses

Make CREATE INDEX ... USING table_range the single interface and remove the
SQL function interface (table_range_create/refresh/drop/summary_count), the
registration table, and the staleness triggers.

- Operator classes are now provisioned automatically by mirroring the types that
  already have a btree or range operator class, re-running on every CREATE EXTENSION.
  So any btree-comparable type and any range type work out of the box, and PostGIS
  geometry registers the moment `CREATE EXTENSION postgis` runs — no manual step.
- summary_build.rs keeps only the ambuild path (scalar min/max + range/geometry
  extent); staleness is maintained by aminsert, recompute via REINDEX; the sql_drop
  event trigger still cleans up dropped indexes/tables.
- Tests rewritten onto CREATE INDEX (26 pass on pg18); dropped the two function-only
  tests (refresh needs REINDEX which can't run in a pg_test txn; drop is covered by
  the AM drop test).
- README/benchmark updated. Honest planning-time note: owning summaries in a real
  index adds per-partition index-metadata overhead during planning (~85 ms flat on a
  bare 1000-partition table); pruning still removes ~110 ms of child-path planning.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: bitner

README.md

@@ -12,41 +12,41 @@ without it.
 
 ## Quick Start
 
-Two equivalent interfaces build and maintain the per-partition summaries. Use whichever
-fits your workflow.
-
-### Function interface
+Summaries are built and maintained through a custom index access method, so pruning
+follows the normal index lifecycle (`pg_dump`/restore, `REINDEX`, `DROP INDEX`).
 
 ```sql
 CREATE EXTENSION pg_table_range;
 
--- Register one or more columns of a partitioned (or plain) table and build summaries.
--- Pass the relation as an OID; cast a name with ::regclass::oid.
-SELECT table_range_create('events'::regclass::oid, ARRAY['val', 'created_at']);
+-- Summarize one or more columns of a partitioned (or plain) table.
+CREATE INDEX events_tr ON events USING table_range (val, created_at);
 
--- Queries now prune partitions whose summarized range cannot match the predicate.
+-- Queries now prune partitions whose summary cannot match the predicate.
 -- Verify with EXPLAIN: non-matching partitions disappear from the plan.
 EXPLAIN (COSTS OFF) SELECT * FROM events WHERE val >= 250;
 
--- Recompute after bulk loads (also clears staleness); or drop registration entirely.
-SELECT table_range_refresh('events'::regclass::oid);
-SELECT table_range_drop('events'::regclass::oid);
-```
-
-### Index interface
-
-```sql
--- Builds the same summaries via a custom index access method.
-CREATE INDEX events_tr ON events USING table_range (val, created_at);
-
--- Pruning works immediately; REINDEX rebuilds summaries after heavy churn.
+-- Recompute after heavy churn; or drop the summaries entirely.
 REINDEX INDEX events_tr;
 DROP INDEX events_tr;   -- removes the summaries it built
 ```
 
 The index is never used for scans — it exists only to build and own the summaries — so
 it adds no scan-time overhead and is never chosen by the planner for data access.
 
+### Supported column types (no setup, including PostGIS)
+
+`CREATE INDEX … USING table_range` works on any **btree-comparable** type and any
+**range** type out of the box. The required operator classes are provisioned
+automatically by mirroring the types that already have a btree/range operator class — and
+that mirror re-runs whenever an extension is installed, so **PostGIS geometry works the
+moment you `CREATE EXTENSION postgis`, with no extra step**:
+
+```sql
+CREATE EXTENSION postgis;                              -- geometry opclass auto-registers
+CREATE INDEX places_tr ON places USING table_range (geom);
+EXPLAIN (COSTS OFF) SELECT * FROM places WHERE geom && ST_MakeEnvelope(0,0,10,10);
+```
+
 ## How it works
 
 - **Summaries.** For each leaf partition and indexed column, one row in
@@ -69,12 +69,12 @@ it adds no scan-time overhead and is never chosen by the planner for data access
   is pruned by testing the constant against the partition's stored extent with
   PostgreSQL's own `&&` operator — so a partition is eliminated when its extent cannot
   overlap the query.
-- **Automatic correctness.** Data changes mark the affected partition's summaries
-  *stale*, and stale summaries are never used for pruning — so a change can never cause a
-  missing row. The function interface installs row-level triggers
-  (`INSERT`/`UPDATE`/`DELETE`/`TRUNCATE`); the index interface marks stale from
-  `aminsert`. `table_range_refresh` (or `REINDEX`) recomputes and re-enables pruning.
-  A `sql_drop` event trigger removes summaries for any dropped relation or index.
+- **Automatic correctness.** An insert that extends a partition marks its summary
+  *stale* (via the index's `aminsert`), and stale summaries are never used for pruning —
+  so a change can never cause a missing row. Deletes only shrink a partition's true
+  range, so the summary stays conservatively wide and remains safe. `REINDEX` recomputes
+  and re-enables pruning after churn, and a `sql_drop` event trigger removes a dropped
+  index's (or table's) summaries.
 
 ## Performance
 
@@ -84,10 +84,15 @@ paths for every partition. On a 1000-partition table queried by a non-key column
 
 | | Planning time | Result |
 |---|---|---|
-| pruning off | ~125 ms | 50 rows |
-| pruning on  | ~17 ms  | 50 rows |
+| pruning off | ~210 ms | 50 rows |
+| pruning on  | ~100 ms | 50 rows |
+
+Pruning removes ~110 ms of child-path planning here. Note the absolute numbers are higher
+than they could be: because summaries are owned by a real index, PostgreSQL loads index
+metadata for every partition during planning (a flat overhead, ~85 ms on this bare
+1000-partition table — proportionally smaller when partitions already carry indexes).
 
-Summaries are loaded **once per plan** (not per partition); the
+Summaries themselves are loaded **once per plan** (not per partition); the
 `e2e_per_plan_cache_loads_once_regardless_of_partitions` test asserts exactly one
 catalog load for a 64-partition query.
 
@@ -114,20 +119,18 @@ Everything not listed is conservatively **kept** (never mispruned):
 
 ## Catalog
 
-- `table_range_summary` — one summary row per (owner, leaf partition, column):
+- `table_range_summary` — one summary row per (index, leaf partition, column):
   `index_oid`, `relid`, `attnum`, `kind` (`minmax` or `overlap`), `type_name`,
   `min_summary`, `max_summary`, `has_nulls`, `all_nulls`, `stale`, `tuple_version`.
-- `table_range_registered` — parents registered through the function interface and their
-  columns.
 
 ## Project layout
 
 | File | Responsibility |
 |------|----------------|
 | `src/lib.rs` | GUCs, `_PG_init`, catalog/bootstrap SQL, test wiring |
-| `src/summary_build.rs` | SPI summary build/refresh/drop, registration, staleness triggers |
+| `src/summary_build.rs` | SPI summary build (scalar min/max + range/geometry extent) |
 | `src/prune_hook.rs` | planner + pathlist hooks, per-plan cache, typed in-memory evaluation |
-| `src/index_am.rs` | `table_range` index access method and operator classes |
+| `src/index_am.rs` | `table_range` index access method + automatic operator-class provisioning |
 | `src/e2e_tests.rs`, `src/index_am_tests.rs` | end-to-end tests |
 
 ## Building and testing
@@ -149,7 +152,5 @@ range-type tests, which exercise the same code path.
 
 - `NOT IN` / `<> ALL`, `NOT (...)`, expression predicates, and parameterized
   prepared-statement plans are kept rather than pruned.
-- Summaries are exact at build/refresh time; between changes and a refresh the affected
-  partitions are simply not pruned (always correct, just less selective).
-- The index interface marks a partition stale on insert; recompute with `REINDEX` (or
-  `table_range_refresh` for the function interface) to re-enable pruning after churn.
+- Summaries are exact at build time; an insert that extends a partition marks it stale
+  (not pruned, but still correct) until the next `REINDEX`.

bench/planning_benchmark.sql

@@ -28,7 +28,7 @@ FROM generate_series(1, :part_count) g,
 
 ANALYZE bench_events;
 
-SELECT table_range_create('bench_events'::regclass::oid, ARRAY['val']);
+CREATE INDEX bench_events_tr ON bench_events USING table_range (val);
 
 \echo '==================== pruning OFF ===================='
 SET table_range.enable_pruning = off;