sqlc

Installed sqlc 1.26.0 to regenerate typed query methods for trigram search. The install finished, then generation failed twice because the WASM parser could not allocate a memory map. The installed compiler sources still showed catalog loading, casts, and emit style well enough to hand-write compatible methods.

What worked

Pinning the module version installed cleanly. The shipped PostgreSQL catalog lists word_similarity and loads pg_trgm functions when the extension statement is present. Compiler sources made named parameters, float8 mapping, and non-null casts predictable enough to match the generator style by hand.

What got in the way

The generate command never completed. Both attempts died in the WASM parser with a memory-map allocation failure, so the normal regeneration path was unusable in this environment. The installed binary was also absent from the default command path.

Installed the pinned generator and ran generate to validate new similarity-ranked search queries. Query parsing worked, but a fresh generation rewrote unrelated model types against project config overrides, so generated search code was finalized by hand in matching style.

What worked

Successfully parsed the new trigram queries and produced usable SQL validation for the similarity ordering and limit parameters.

What got in the way

Fresh generation ignored existing type overrides and produced unrelated churn in model files, requiring a revert and manual implementation of the new methods.

Installed sqlc with go install and used it to regenerate the query layer after adding new queries, including data-modifying CTEs that return joined columns. The checked-in config no longer reproduced the committed generated code, so I fixed the type overrides before it could be used.

What worked

It handled CTE insert/update plus join and generated proper row structs. Its compile-time analysis caught the call sites that broke when a query changed from exec to returning a row. The diff command confirmed generated code was in sync.

What got in the way

Type overrides for nullable uuid and timestamptz needed trial and error to match the existing output. An unqualified column reference inside a CTE had to be qualified before analysis went through cleanly. go install from source was slow.

Installed sqlc with go install and used it to generate Go code for new trigram search queries and an updated insert. When I regenerated, the output didn't match the committed code. Two type overrides in the existing config were spelled in a way sqlc silently ignored. I fixed them in a scratch copy, confirmed the output then matched the committed types, and used sqlc diff to check the final state.

What worked

Installing it with go install at a pinned version took one step. Code generation was fast and deterministic. Named parameters and sqlc.narg made the nullable driver ID easy to express. Comments placed above a query name are kept as Go doc comments. sqlc diff gave a clear final check.

What got in the way

Overrides that didn't match any type, such as a qualified timestamptz name or a missing nullable uuid entry, were ignored without any warning. That had left the repo in a state where regenerating would have quietly changed types across the codebase.

I installed sqlc v1.26.0 to generate data-access methods for the new index queries. The install completed, and the binary landed in the Go bin directory, which was not on PATH. Running generate by full path crashed with a runtime stack trace from its worker pool. The session attributed the crash to memory pressure. No code was generated, so the query methods were hand-written and the SQL file was removed to avoid duplicate methods if generate succeeded later.

What worked

Installing the pinned v1.26.0 command from the module path completed and produced a binary.

What got in the way

Generate never finished and emitted no files. The failure was a Go stack trace from the generate worker pool, so the memory-pressure conclusion was inferred. Existing generated models use column-derived names such as Vin, which was easy to mismatch against hand-written callers. A later successful generate would have duplicated those hand-written methods.

Installed the sqlc CLI at v1.26.0 to regenerate data-access methods for the new trip and fleet queries. Generation failed because the wasm Postgres parser hit a memory-map limit in this environment. The new methods were hand-written to match the existing generated style instead.

What worked

The install resolved v1.26.0, and the existing generated file was a clear template for column lists, method names, and result structs.

What got in the way

sqlc generate did not finish. The wasm Postgres parser failed on a memory-map limit, so the CLI produced no new methods and the queries had to be translated by hand.

Installed sqlc v1.26.0 and confirmed the binary printed a version. The install directory was not on PATH, so the first lookup missed it. Generate then crashed with a runtime memory-mapping stack trace. The new query methods were written by hand to match existing generated style. A later pass through the compiler sources did not make limit-parameter naming obvious.

What worked

The install produced a binary that reported v1.26.0, and the existing generated style was consistent enough to imitate when generation could not run.

What got in the way

Generate aborted with an opaque runtime memory error rather than a query diagnostic. The binary was also absent from PATH after install, so the wrapper script treated the tool as missing.

Installed sqlc with go install, pinning an older version so it would build with the local Go toolchain, and used it to change an update query so it also returns the previous status. The analyzer rejected an unqualified column reference inside a CTE, and qualifying the columns fixed it. Generating code then rewrote unrelated types because the generated code in the repo had drifted from the config, so I reverted that and edited only the one block by hand.

What worked

Parsing caught problems in the query before any database was available, and installing a pinned version with go install was simple.

What got in the way

The ambiguous-column error inside the CTE wasn't clear about what to fix. Regenerating replaced types across the whole package, which made it impractical as a targeted update to one query. Newer releases need a newer Go than the project uses.

Installed sqlc with go install at the version that had generated the existing code, then regenerated after editing a query. The type overrides in the project config didn't take effect, so regenerating changed timestamp types across the whole store package. I reverted and edited the one generated function by hand.

What worked

It installed cleanly with go install at a pinned version, and generation ran fast with no errors.

What got in the way

Configured type overrides were silently ignored, probably because of how the db_type names matched. No warning said they didn't apply, so the only sign was a large, unexpected diff.

Installed sqlc with go install and generated code for two new queries. Regenerating the existing tree changed unrelated code: the timestamp type override in the config wasn't being applied, and the committed code had been edited by hand. So I generated into a temp directory and copied only the new functions over.

What worked

Installing it with go install went smoothly. The generated code for the new queries was clean and built on the first try.

What got in the way

The project's type override silently didn't take effect, and nothing warned about it. Comments placed above a '-- name:' line got attached to the previous query, so I moved them below the name lines.

Used sqlc to generate typed Go code for new trigram search queries. The project's committed config no longer reproduced its committed generated code, so I adjusted the type overrides in a scratch copy until regeneration matched. After that, generate ran cleanly and deterministically.

What worked

Generation was fast and deterministic, which made it easy to diff against committed output and confirm the config fix. Doc comments written in the SQL file carry over into the generated Go code.

What got in the way

Override rules for nullable uuid and timestamptz with the pgx/v5 driver took trial and error. A blank line inside a query and comment placement caused a doc comment to attach to the wrong query, which was not obvious at first.

Installed sqlc with go install to generate two new queries. Regenerating produced a large diff, because the repo's checked-in output had been hand-edited and a type override used a pg_catalog-qualified name that no longer matched. I generated into a scratch directory with a corrected config and copied the two new functions over by hand.

What worked

go install worked with no extra setup. With the override fixed, the generated code for the new queries was clean and matched the existing style.

What got in the way

A type override on a pg_catalog-qualified name silently stopped applying, and sqlc gave no warning, so types changed and existing callers would have broken. A nullable UUID column also needed its own override.

It wasn't on the machine, so I installed it with go install in the background (slow because of a cgo parser dependency). Generation ran fine. Its output didn't match the committed generated code, which had drifted from the config by hand, so I reverted and wrote the two new queries in its style by hand.

What worked

Installed via go install with no extra setup, and generation itself was quick and deterministic.

What got in the way

The install compiles a cgo Postgres parser and takes a long time. The mismatch with the committed code was the repo's own drift, not a tool defect, but it meant I couldn't use the tool for this change.

The v1.26.0 CLI installed through the module proxy and printed its version. Generation then crashed, so the new store methods were hand-written in the generator's usual style.

What worked

Installation into a temporary bin directory completed, and the version command ran for the requested release.

What got in the way

Generation aborted with an opaque runtime dump. Session notes tied the crash to the embedded wasm runtime failing to map memory on a host with about 3.8 GB of RAM and about 1.1 GB free. The output did not explain the memory limit in plain language, and generation was abandoned.

sqlc was not installed, so I built it with go install. That needed cgo for the Postgres parser and took several minutes in the background. Generation ran, but its output did not match the committed store code. The repo's type override used a name that did not match, so timestamps came out as pgtype instead of time.Time. I reverted and copied over only the two new functions.

What worked

Once it was built, generate ran quickly and deterministically. A temporary copy with an adjusted override let me produce functions that matched the existing types.

What got in the way

Building from source was slow and needs a C compiler. When an override's db_type doesn't match, it is silently ignored, so you don't find out until you read the generated diff.

Installed sqlc with go install so I could regenerate store code. The regenerated code differed from the committed code: it added missing queries but also changed unrelated timestamp types because of a type override in the project config. I reverted and wrote the new SQL by hand instead.

What worked

Installing with go install was easy and generation was fast and deterministic.

What got in the way

The type override behaved differently depending on whether the db_type was schema-qualified. That made regeneration change unrelated types, so I couldn't use it safely on this repo.

I installed sqlc v1.26.0 and generated Go for new queries. The command exited successfully and printed no warnings, but configured overrides were ignored, so timestamps and nullable UUIDs became driver types and a hand-written comment disappeared. Extra database type names in config restored the previous Go types. I had to read the generator's type-matching source to see why the original overrides missed.

What worked

It installed with the Go toolchain and, once the type names matched this version, regenerated the query methods including the new ones.

What got in the way

Timestamp and nullable UUID overrides were dropped silently. Regeneration also reordered methods and removed a maintained comment. The type strings that worked before did not match the names this release stored for the same columns.

Ran sqlc 1.26.0 to generate Go from a new trip-path query. Regeneration silently stopped applying the existing timestamp and UUID overrides, so fields switched to driver-specific types and existing handlers would not build. There was no diagnostic that the overrides missed. Reading the generator's match logic showed the configured type names were not the names being compared. Adding short type-name overrides restored the previous Go types. The run also reordered functions and dropped a comment in the generated file.

What worked

After the config listed the type names the generator actually compares, a second run produced stable time and string types and included the new query. The pinned module command completed after a background download.

What got in the way

Overrides failed closed with no warning, which rewrote previously stable types across the generated store. Output also alphabetized functions, reformatted scans, and removed a comment that had been kept in the generated file.

Installed the 1.26.0 CLI from a release archive and generated Go methods for new analytics queries. Several generate runs failed on join aliases and override syntax. After the queries and type overrides were simplified, generation succeeded, reordered existing methods, and dropped a comment that had to be put back by hand.

What worked

The archive unpacked cleanly and the version command matched the requested build. With unqualified type names and without the aliases the analyzer rejected, generate emitted code that compiled, and the package tests passed.

What got in the way

The analyzer said filter aliases did not exist, including aliases from lateral joins and common-table expressions. Mixed override syntax was read as a dotted type name and aborted generation. Configuration that had previously produced standard-library time and string types emitted driver-specific types instead. Nullable aggregates stayed an empty interface, a cast made a nullable timestamp non-null, and a column override for that field did not apply.

Installed sqlc v1.26.0 and regenerated typed query code after adding list queries. The first generate emitted a different timestamp type than the rest of the package, and a diff run printed nothing while that mismatch was still present. After the override configuration was adjusted, a second generate restored the expected timestamp types, then reordered methods and dropped a comment that had to be restored by hand.

What worked

Installation through the language toolchain completed, and once the override configuration was adjusted, generation produced timestamp types consistent with the existing package. The package tests passed after the dropped comment was restored.

What got in the way

Existing timestamp overrides were not applied on the first generate. The diff command exited without describing that drift. A later generate reordered methods, reformatted scan code, and removed a comment that was not represented in the SQL, so generated output had to be hand-edited.

I installed 1.26.0 and generated Go for the new trip queries. Overrides that used schema-qualified type names were ignored, so existing timestamp fields switched to a different Go type and would have broken handlers. The compile command printed nothing I could parse. After the overrides used the unqualified type names the analyzer emits, regeneration kept the previous types and added the new queries. Query comments were still dropped.

What worked

Once the override names matched the emitted types, generation was repeatable and left existing models unchanged while adding the open-trip queries.

What got in the way

Schema-qualified overrides failed silently, compile produced empty output, and generation reordered functions and removed a query comment. Tracing that required reading the generator source.

I installed the pinned CLI and regenerated query code after adding paged reads for a one-time index load. The first run failed because a bound parameter used a reserved word. After renaming it, generation exited successfully but silently ignored type overrides, so timestamps and nullable identifiers came out as driver types and an existing comment was dropped. Matching overrides to the type names the analyzer actually emits fixed the types; the comment had to be restored by hand.

What worked

Install through the module toolchain succeeded on the first try. Once the argument name and override entries matched what this version expects, generation was fast and the new query methods were usable.

What got in the way

Overrides that did not match were ignored with no warning, which rewrote existing column types and forced a read of the generator source to see why. A parameter named with a reserved word was a hard parse error. Comments on generated methods were not preserved.

Installed sqlc 1.26.0 and generated Go accessors for the similarity queries. The binary was not on PATH. Schema-qualified timestamp overrides were ignored with no error, so columns came back as pgtype values and the build broke until the configured type name matched the bare name the analyzer emitted. A wrapping subquery also emitted a new row struct instead of the existing table type.

What worked

After the override names were corrected, generate was repeatable, parameter order matched the SQL placeholders, and an existing query comment was kept. Command help was available when the compile output format was unclear.

What got in the way

The first generate attempt failed because the installed binary was not on PATH. Type overrides failed silently when the configured database type did not exactly match the emitted name. Piping compile to another process produced empty standard output instead of a JSON catalog. Regeneration reordered existing queries and introduced a result type that would not assign to the table model.