fix(migration): use PERFORM for add_compression_policy inside DO block

[TerrifiedBug]

Summary

Fourth in the TimescaleDB-demo bring-up bug series (after #179, #180, #181). Once #181 fixed the camelCase identifier quoting, the migration hit yet another error on a fresh TimescaleDB volume:

ERROR: query has no destination for result data
HINT: If you want to discard the results of a SELECT, use PERFORM instead.
WHERE: PL/pgSQL function inline_code_block line 12 at SQL statement

Inside a PL/pgSQL DO block, a bare SELECT is illegal unless its result is captured (SELECT ... INTO). To discard the result, you must use PERFORM. The four add_compression_policy(...) calls in this migration use SELECT, so the very first one aborts the whole block.

The four ALTER TABLE ... SET (timescaledb.compress, ...) statements in the same block are fine — only the add_compression_policy calls need fixing.

Fix

Four-line change. Each SELECT add_compression_policy( becomes PERFORM add_compression_policy(. Table names, options, indentation untouched.

Why this didn't surface earlier

Same as #179 / #180 / #181: every prior deployment ran on plain Postgres, where the IF EXISTS (... timescaledb) guard makes this whole migration a no-op. Now that the prior three PRs let the body actually execute under TimescaleDB, this latent PL/pgSQL syntax bug is the next one in line.

Recovery instructions

For anyone whose DB is currently in the failed state on this migration:

Option A — wipe and reapply (cleanest if no real data, e.g. demo):

docker compose down -v
docker volume ls | grep vf-demo-pg   # verify gone, manual rm if needed
docker compose up

Option B — preserve data:

npx prisma migrate resolve --rolled-back 20260329000001_timescaledb_compression
npx prisma migrate deploy

Drift warning for plain-Postgres users

Same caveat as #179 / #180 / #181: the migration's checksum changes. On next prisma migrate deploy you may see a "migration was modified after applied" warning. Resolve with:

npx prisma migrate resolve --applied 20260329000001_timescaledb_compression

One-time fix; the no-op behaviour on plain Postgres is unchanged.

Test plan

• Visual inspection — exactly 4 lines changed, all SELECT add_compression_policy( → PERFORM add_compression_policy(
• Drop the demo postgres volume
• docker compose up against timescale/timescaledb:2.16.0-pg16 — both 20260329000000 and 20260329000001 apply cleanly through to completion
• Confirm the four compression policies exist: SELECT hypertable_name, proc_name FROM timescaledb_information.jobs WHERE proc_name = 'policy_compression'; — should return rows for PipelineMetric, NodeMetric, PipelineLog, NodeStatusEvent

Prior PRs in this series

• fix(migration): quote table names in create_hypertable calls #179 — quote table names in create_hypertable
• fix(migration): include id in compress_orderby for hypertables #180 — include id in compress_orderby to satisfy unique-index constraint
• fix(migration): quote camelCase identifiers in compression option strings #181 — quote camelCase column identifiers in compress_segmentby / compress_orderby option strings

[greptile-apps]

Greptile Summary

Replaces four SELECT add_compression_policy(...) calls with PERFORM add_compression_policy(...) inside a PL/pgSQL DO block. This is the correct fix: PL/pgSQL requires PERFORM to discard a function's result when no INTO target is provided, and the bare SELECT was causing the entire block to abort with "query has no destination for result data". The change is exactly scoped to the four affected lines, with no other modifications.

Confidence Score: 5/5

Safe to merge — the four-line change is correct PL/pgSQL and precisely fixes the stated runtime error.

The fix is surgically scoped, PL/pgSQL-correct, and the existing if_not_exists => true guard ensures idempotency. No logic, security, or correctness issues introduced.

No files require special attention.

Important Files Changed

Filename	Overview
prisma/migrations/20260329000001_timescaledb_compression/migration.sql	Four SELECT → PERFORM substitutions in the DO block; fix is minimal, correct, and leaves all surrounding SQL untouched.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[DO $$ BEGIN] --> B{timescaledb extension\nexists?}
    B -- No --> C[RAISE NOTICE: skipping]
    B -- Yes --> D[ALTER TABLE PipelineMetric SET compress options]
    D --> E[PERFORM add_compression_policy PipelineMetric]
    E --> F[ALTER TABLE NodeMetric SET compress options]
    F --> G[PERFORM add_compression_policy NodeMetric]
    G --> H[ALTER TABLE PipelineLog SET compress options]
    H --> I[PERFORM add_compression_policy PipelineLog]
    I --> J[ALTER TABLE NodeStatusEvent SET compress options]
    J --> K[PERFORM add_compression_policy NodeStatusEvent]
    K --> L[RAISE NOTICE: policies enabled]
    C --> M[END $$]
    L --> M

Loading

_{Reviews (1): Last reviewed commit: "fix(migration): use PERFORM for add_comp..." | Re-trigger Greptile}