feat(bff): WithPostgresManagedSchema for a migration-owned session table

[ovander]

What and why

Closes #82. bff.NewPostgresStore always ran CREATE TABLE IF NOT EXISTS and CREATE INDEX IF NOT EXISTS. PostgreSQL checks CREATE on the schema, and table ownership for the index, before it checks whether the object exists. So a least-privilege BFF role, with USAGE on the schema and SELECT, INSERT, UPDATE, DELETE on a migration-owned table, could not start the store. I reproduced it on PostgreSQL 16 with exactly Lakebridge's layout (schema bff, search_path=bff):

ERROR:  permission denied for schema bff
ERROR:  must be owner of table sessions

The new option bff.WithPostgresManagedSchema() is additive, and the default is unchanged:

• The store runs no DDL.
• At start-up it checks that the table has the store's columns (SELECT id, data, created_at, last_seen, deleted_at … LIMIT 0).
• It also checks that the role holds each of SELECT, INSERT, UPDATE and DELETE, and fails naming the missing privilege. This goes beyond the issue's proposal: a role without DELETE would otherwise start and only fail at the first sign-out. There is one has_table_privilege call per privilege, because given a list it returns true when any of them is held (verified on PostgreSQL 16).
• The doc comment gives the exact CREATE TABLE and CREATE INDEX the migration must run. The table name stays an unqualified, checked identifier, so the schema comes from the role's search_path.

How it was tested

• TestPostgresStore_ManagedSchema:

  • On a missing table, the managed store refuses to start and creates nothing.
  • On a migration-created table without the index, sessions round-trip and delete, and no <table>_last_seen_idx appears afterwards, which proves no DDL ran.

• TestPostgresStore_ManagedSchemaChecksTheTable:

  • The owner revokes its own DELETE (allowed in PostgreSQL), and start-up fails naming DELETE.
  • A table without the store's columns is refused.

• By hand, with a real CRUD-only role on PostgreSQL 16, in Lakebridge's exact layout:

  • The default mode fails with permission denied for schema bff, as reported.
  • The managed mode starts and runs Put, Get, Delete and Sweep cleanly.

  The scratch role and database were removed. CI's database role can't create roles, so this isn't an automated test; the two tests above cover the same paths.

• go mod tidy && git diff --exit-code go.sum leaves go.sum unchanged

• go build ./... passes

• go vet ./... passes

• go test -race -count=1 -timeout=120s ./... passes (with TEST_DATABASE_URL; all 8 PostgresStore tests run)

• golangci-lint run ./... (v2.14.0) reports no issue

• govulncheck ./...: CI (the sandbox can't reach vuln.go.dev)

• A line is added under ## [Unreleased] in CHANGELOG.md

Compatibility

• Exported-API change: yes, it adds bff.WithPostgresManagedSchema() PostgresStoreOption.
• Behaviour change for existing callers: none. Without the option, the store creates its table as before.
• Breaking change: none.

Release note: with the Go 1.27.1 requirement already on main, this makes the next minor (v1.20.0) a real feature release. Lakebridge moves to Go 1.27.1 with it, as stated in #82.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GKRxaeYxyDhmt42cehLsGA

---

Generated by Claude Code