The console's database pool keeps a search_path from db-dsn, while the documentation and the spec say it uses core,public #264

New Issue

2026-10-24T06:52:46Z

cgalo5758 commented

2026-10-24 06:52:46 +00:00

What happens

db.Connect opens the runtime pool, the one the console serves from, through keepSearchPath (internal/db/database.go): when the db-dsn connection string carries a non-empty search_path parameter, the pool opens with that value, and only a string that carries none gets core,public. TestStartupParamsWinOverTheString (internal/db/startup_params_test.go) pins this behavior: a string carrying Search_Path=decoy_a gives the runtime pool decoy_a.

Two other sources state a different rule:

docs/database-management.md, section "Migrations Run With search_path=public": "The application's pool, opened by db.Connect on db-dsn, uses core,public and role=none."
openspec/specs/postgres-database/spec.md, requirement "PostgreSQL connection via pgx driver": "the system SHALL ensure search_path = core, public", and its scenario says the connection's search_path SHALL be set to core, public. The same requirement's "search_path failure" scenario describes a SET search_path after connecting, a step the code no longer has: the path is a startup parameter.

The migration connection (db.ConnectMigration) follows the replacing rule: it opens with search_path=public whatever the string carries.

What should happen

One rule, stated the same way by the code, its test, docs/database-management.md and the spec. Which rule is right is the open question:

the runtime pool always opens with core,public, replacing any search_path the string carries, as the documentation and the spec say and as the migration connection does with public; or
an operator may set the runtime pool's search_path in db-dsn, as the code and its test do, and the documentation and the spec say so, including what the path must contain.

Where

internal/db/database.go (keepSearchPath, openAndConfigureDB)

Steps

Read the case "mixed-case keys" in startupCases (internal/db/startup_params_test.go): it expects the runtime pool to report the string's decoy_a.
Read docs/database-management.md and openspec/specs/postgres-database/spec.md: both say the pool uses core,public.

Why it matters

An operator who follows the documentation expects a search_path in db-dsn to be replaced, as the migration connection replaces it, and gets a pool that resolves unqualified names wherever the string says.

### What happens `db.Connect` opens the runtime pool, the one the console serves from, through `keepSearchPath` (`internal/db/database.go`): when the `db-dsn` connection string carries a non-empty `search_path` parameter, the pool opens with that value, and only a string that carries none gets `core,public`. `TestStartupParamsWinOverTheString` (`internal/db/startup_params_test.go`) pins this behavior: a string carrying `Search_Path=decoy_a` gives the runtime pool `decoy_a`. Two other sources state a different rule: - `docs/database-management.md`, section "Migrations Run With `search_path=public`": "The application's pool, opened by `db.Connect` on `db-dsn`, uses `core,public` and `role=none`." - `openspec/specs/postgres-database/spec.md`, requirement "PostgreSQL connection via pgx driver": "the system SHALL ensure `search_path = core, public`", and its scenario says the connection's `search_path` SHALL be set to `core, public`. The same requirement's "search_path failure" scenario describes a `SET search_path` after connecting, a step the code no longer has: the path is a startup parameter. The migration connection (`db.ConnectMigration`) follows the replacing rule: it opens with `search_path=public` whatever the string carries. ### What should happen One rule, stated the same way by the code, its test, `docs/database-management.md` and the spec. Which rule is right is the open question: - the runtime pool always opens with `core,public`, replacing any `search_path` the string carries, as the documentation and the spec say and as the migration connection does with `public`; or - an operator may set the runtime pool's `search_path` in `db-dsn`, as the code and its test do, and the documentation and the spec say so, including what the path must contain. ### Where `internal/db/database.go` (`keepSearchPath`, `openAndConfigureDB`) ### Steps 1. Read the case "mixed-case keys" in `startupCases` (`internal/db/startup_params_test.go`): it expects the runtime pool to report the string's `decoy_a`. 2. Read `docs/database-management.md` and `openspec/specs/postgres-database/spec.md`: both say the pool uses `core,public`. ### Why it matters An operator who follows the documentation expects a `search_path` in `db-dsn` to be replaced, as the migration connection replaces it, and gets a pool that resolves unqualified names wherever the string says.

cgalo5758 added the

labels 2026-10-24 06:52:46 +00:00

Sign in to join this conversation.