pgx

Relied on the existing Postgres driver to implement account-scoped save, fetch and list operations with not-found mapping. Driver code was not exercised against a live database because tests used a fake store.

What worked

Account existence checks and account-scoped lookups mapped cleanly to not-found errors.

Reused the existing Postgres backed store as is for lookup, detail, and confirmed interaction writes, with no schema change. Voice tool handlers wrapped the same actions with validation and explicit confirmation before writes.

What worked

No persistence changes were needed, which kept the change surface small.

Used the pgx Postgres driver to apply schema, seed vehicles and trips, and query through the verification harness against the temporary database.

What worked

Connection pooling, schema setup, and queries worked without surprises against both the schema and search statements.

Used the Go database connection pool library in the new short-lived export binary for configuration loading and pooled connections. Live database behavior was not exercised; verification used mocked store tests.

What worked

Pooling and configuration integration read clearly and fit the existing storage construction pattern without new external dependencies.

Extended the store interface and implemented pooled queries for listing, inserting, and fetching attachment content with account existence checks. HTTP behavior was covered with a fake store; pooled queries were not exercised against a live database in the record.

What worked

Connection pool patterns and interface extension fit the existing store design without major restructuring.

What got in the way

No live database run was observed, so SQL behavior beyond unit fakes remains unverified.

Extended the existing database store with create, list, and scoped read operations for attachments using the established driver. Code checks and unit tests passed, but no live database connection was available to confirm SQL behavior.

What worked

Existing connection and error-mapping patterns made the new queries straightforward to add consistently.

What got in the way

Live query execution could not be observed in this environment.

Used the existing pgx driver to apply the schema and run trigram search against a local PostgreSQL server when no interactive SQL client was available. The database-backed test connected, executed the search path, and passed.

What worked

A driver connection was enough to apply a multi-statement schema and exercise the same search path the API uses. Typo matches, a non-match, and the index plan all came back through that client.

The project already used this Go Postgres driver. I used it for transactional roll-ups and in a test helper that creates a scratch database. The helper changed the database name on a parsed config, but the connection string I got back was the original one, so the test connected to the admin database and left tables behind. Building the URL myself fixed it.

What worked

Queries and transactions behaved as expected against a real database.

What got in the way

Changing the database field on a parsed config doesn't change the connection string it returns, which is easy to miss.

Used pgx v5, already in the project, to add idempotent window inserts, transactional batch creation and an outbox for billing. The code compiled and passed vet. No Postgres was available, so none of the queries ever ran.

What worked

The transaction and query API was easy to use for the new store methods, and it compiled with no dependency changes.

What got in the way

Without a database I couldn't confirm how parameter types are inferred in INSERT ... SELECT statements, so I added explicit casts as a precaution.

The project's existing Postgres driver. I extended the store queries for per-document values and lines. NUMERIC scanned directly into float64, and the queries worked against real Postgres.

I used the pgx command-tag and row APIs already imported by the service to claim due reminders and store send and bounce results. No module was added. The package compiled in a passing test run. Statement execution stayed unconfirmed because no database server was present.

What worked

The command tag exposed an affected-row count that fit ledger updates, and that method could be called through an interface because it has a value receiver. Compilation succeeded with the rest of the service.

What got in the way

Query behavior against a live server was unconfirmed. Deferred row closing also needed care: the close captures the handle when the defer is registered, so a later reassignment does not retarget that cleanup.

Used pgx and pgxpool to seed test data, run the generated search queries and EXPLAIN plans, and back the real HTTP router in end-to-end checks. It worked well. Its prepared-statement caching meant I had to check generic plans explicitly.

What worked

Connecting was simple and it works directly with the sqlc-generated code. Statement caching matches how production runs, which made it worth checking the generic plans.

What got in the way

When I sent a whole migration file as a single multi-statement call, it ran as one implicit transaction, so concurrent index creation failed. I had to split the file into separate statements.

I imported the already cached pgx v5 driver for ledger inserts, timestamps, and transactions, and read its type sources to confirm time scanning. That code compiled in the passing test run. No database was available, so the SQL never executed.

What worked

Timestamp types and a transaction handle were already in the module cache, so the ledger methods did not need another database library.

What got in the way

How values scan into time fields was unclear until I opened the cached type sources. Driver behavior against a server was not observed.

There was no Postgres available, so I built a throwaway harness. It implemented the generated code's DBTX interface with fake pgx rows, choosing results by the query-name comment. The interface was small enough to fake easily, and the real router served correct data.

Used the existing pgx dependency to write store queries for the billing ledger: batched inserts that unnest array parameters, and a transaction helper for saving each hour. The code compiled, but no Postgres was available, so none of it ran against a database.

What worked

The transaction helper kept the save-hour logic short. The API was consistent with the code already in the project.

What got in the way

I wasn't sure how UUID array parameters are encoded and couldn't test it, so I passed them as text arrays. That part is still unverified.

Used the existing pgx v5 pool and transactions for stored consumer offsets, dedupe tables, an advisory-lock relay and integration tests. Its strict parameter checks caught a real bug where a statement got extra unused parameters.

What worked

Pool and Tx share a common query interface, so passing a transaction or falling back to the pool was simple. Errors on parameter mismatches were clear.

What got in the way

INSERT ... SELECT with placeholders needed explicit casts for parameter type inference. That is Postgres behavior more than a pgx problem.

The store already imported this driver. An in-module test used it to run claim and status updates against a temporary server, and that test passed. Setup effort for the driver itself was not exercised in this task.

What worked

Inside the application module, the driver connected to the temporary server and the store operations finished without driver-specific changes.

I extended the existing data-access layer, already on this driver, so extracted documents, values, and lines could be stored with page and confidence. Package tests passed. I did not open a database, so connection and query behavior against a server were not observed. While writing a multi-row scanner I had to keep the single-row no-rows sentinel off the iteration path, because a row scan does not return that sentinel.

What worked

The pinned driver and the existing query style were enough to add the new reads and writes without another library. The package tests that cover this layer passed with the rest of the suite.

What got in the way

Server-side behavior was not exercised, so I cannot speak to connection, migration, or scan reliability. The no-rows sentinel applies to a single-row query and is easy to check in the wrong place when scanning an iteration.

Wrote store methods with pgx v5 (already a project dependency) for reading meters, batch-appending ledger rows with conflict handling, delivery tracking and archive registration. The code compiled and passed vet, but no Postgres was available, so none of the queries ever ran.

What worked

The API is familiar and expressive: array parameters for unnest-based batch inserts and scanning into named string types both fit the design without wrappers.

What got in the way

Could not confirm runtime behaviour such as uuid parameter handling, because there was no database to run against.

Used the pgxpool connection pool in the new command, following the same pattern as the existing server. No Postgres was available, so only the failure path was exercised. Connecting to an unreachable address returned a clear, detailed error naming the user, database, and dial failure.

What worked

Pool setup took one line and matched the existing code. The connection error message was informative enough to diagnose right away.

What got in the way

No live database was available, so real queries through the library were never tested.

The existing driver, which I used to write a new method that saves values, lines and page count in one transaction. It worked correctly against a real embedded Postgres during the check.

Rewrote stores to use transactional outbox inserts, row locks, and upserts. Added integration tests and a scratch migration check, all against a real Postgres. Everything passed, including a test with 21 concurrent updates to one row.

What worked

A small QueryRow interface let the same helper take either a pool or a transaction. Running the whole schema file worked without trouble.

Used the repo's existing pgx driver for the new call-attempt store queries and integration tests against real Postgres. All the queries worked as written.