Only install versions reachable from the requested version's upgrade graph

Open
#387 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
postgresql, typescript
Domain
cli, databases

Research direction

Start at the dbdev install path that selects published extension versions, then trace how version and upgrade-script metadata are assembled for pg_tle. Build the connected component containing the requested version and verify that only those versions are installed, while disconnected major-version histories are skipped. Add or run tests covering the 4.x/5.x example and a fully connected upgrade graph.

Written by the indexing model from the issue text.

Description

Feature request

When dbdev install is called for a specific version (or latest), it currently installs every published version of the extension into pg_tle's catalog. This is wasteful when there is no continuous upgrade path across all versions.

Problem

Consider an extension with this version history:

  • 4.0.0, 4.1.0, 4.2.0 (connected via upgrade scripts)
  • 5.0.0, 5.0.0--5.1.0, 5.1.0 (connected via upgrade scripts)
  • No upgrade path from 4.x → 5.x (manual migration required)

When a user requests version 5.1.0, dbdev installs all 4.x versions into pg_tle even though:

  1. No ALTER EXTENSION ... UPDATE path exists from any 4.x version to any 5.x version
  2. Nobody requesting 5.x would fresh-install a 4.x version
  3. The 4.x install scripts are dead weight in the catalog

This adds unnecessary clutter and could confuse users into thinking an upgrade path exists when it doesn't.

Proposed behavior

When installing a specific version, dbdev should build the version upgrade graph and only install versions in the connected component containing the requested version. For the example above, requesting 5.1.0 would only install:

  • 5.0.0 (full install script)
  • 5.0.0--5.1.0 (upgrade script)
  • 5.1.0 (full install script)

The 4.x versions would be skipped entirely.

Additional context

This came up with pointsource/supabase_rbac, which has a major version boundary between v4.x and v5.x with no automated upgrade path. The v5 rewrite changed the data model extensively enough that migration is manual (export/reinstall/reimport).

Dominant language
TypeScript
Stars
443
Forks
31
Avg merge
1h 12m
Merged PRs (30d)
10

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from supabase/dbdev

All issues in supabase/dbdev

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.