Files
llmgw/internal/store/migrations/postgres/0004_admins.sql
T
Ilker ManapandClaude Opus 5 a76ebdb79a
CI / test (push) Successful in 3m11s
Run the store on PostgreSQL, chosen by what the address looks like
A path is still SQLite and a postgres:// URL is PostgreSQL, so every existing
configuration keeps working untouched and moving is one line changed rather
than a new setting to find. An address of the form @/path/to/file reads the
real one out of that file, which is how a DSN carrying a password stays out of
a configuration that gets copied, diffed and pasted into issues.

The driver is pgx, which is pure Go. That is not a preference: the whole binary
is built with CGO_ENABLED=0 so it runs on a node whose libc is older than the
builder's, and a cgo driver would take that away from every deployment,
including the ones still on SQLite.

Tested against a real PostgreSQL, which found two things nothing else could.
The schema_migrations table is created in Go rather than in a migration file,
so it escaped the port and still said INTEGER — 64 bits in SQLite, 32 in
PostgreSQL, and a millisecond timestamp does not fit, so the very first
migration failed to record that it had run. And the memory migration uses an
FTS5 virtual table with three triggers keeping it in step, which has no
counterpart: PostgreSQL derives a tsvector from the row, so there is nothing
to keep in step and no trigger to forget.

That leaves exactly one query that is not the same sentence in both dialects —
the note search, MATCH against @@ — and it is written out twice rather than
hidden behind a shared spelling that would mean something subtly different in
each. Everything else is one set of queries.

The text search uses the 'simple' configuration rather than English. These are
an agent's own notes, in whatever language it chose, and stemming English
rules over Turkish would quietly stop finding things.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-25 16:18:10 +02:00

21 lines
1.1 KiB
SQL

-- Ported from the SQLite migration of the same number. Same version, same
-- meaning, different spelling: SQLite's storage classes and PostgreSQL's types
-- do not line up, and one shared file would be a promise neither could keep.
--
-- Times are milliseconds since the epoch in BIGINT, exactly as in SQLite,
-- rather than TIMESTAMPTZ. The Go code reads and writes int64 milliseconds
-- everywhere; converting here would mean two time representations in one
-- codebase, and the conversion would be the thing that is wrong at 2am.
-- Who may see the cluster.
--
-- Until now the answer was "whoever has a shell on the control plane", because
-- the dashboard lived on a loopback-bound port. Serving it over the web needs
-- an actual answer, and this is the smallest one that is not a lie: a flag on
-- an account that already has a password, a session and a CSRF token.
--
-- Deliberately not a role system. One bit is enough for "can see the cluster"
-- and impossible to get subtly wrong; roles arrive when there is a second
-- distinction worth drawing.
ALTER TABLE users ADD COLUMN is_admin BIGINT NOT NULL DEFAULT 0;