fix(postgres): re-parse unnamed statement after resolving custom-type OIDs

[DoTuanAnh2k1]

Why

A non-persistent query (persistent(false)) that references a type whose OID is not built-in or cached fails the first time that type is seen on a connection:

error returned from database: unnamed prepared statement does not exist (SQLSTATE 26000)

Thanks to @patrickt's diagnosis in #4305: for persistent(false) the query is parsed as the unnamed statement. Resolving the OID of a custom result type (resolve_statement_metadata → fill_cache) runs a catalog lookup over the simple query protocol, and per the Postgres protocol a simple Query destroys the unnamed prepared statement. That happens after Parse but before Bind, so the Bind fails. Named (persistent) statements are unaffected, which is why it only reproduces with persistent(false) on a cold type-OID cache. It's a regression from 0.8.

The module already anticipates exactly this case:

…we'd have to replace the unnamed prepared statement which is already the one the user wanted to execute. This means we'd have to immediately re-prepare it, adding an extra round trip.

What changed

TypeResolver/ColumnResolver::fill_cache and resolve_statement_metadata now report whether they actually ran a catalog lookup. In prepare, when the statement is unnamed and such a lookup ran, the unnamed statement is re-parsed before returning, so the following Bind can reference it. The extra Parse only happens on the persistent(false) + cold-cache path that already pays for the catalog round-trip; the common path is unchanged.

Testing

Added test_issue_4305: a persistent(false) query returning a custom enum on a fresh connection. It fails with SQLSTATE 26000 on the current code and passes with the fix. The full tests/postgres/postgres.rs suite passes (57 passed, 0 failed), including the existing custom-type/array/domain tests. cargo fmt --check and cargo clippy -p sqlx-postgres are clean.

Fixes #4305.

---

_{Disclosure: prepared with AI assistance.}

[samuelselleck]

Just chiming in to say that we are hitting this when trying to upgrade as well! Appreciate this being fixed.

[DoTuanAnh2k1]

Thanks for the extra data point — good to know it's biting more than one upgrade. Hopefully it gets a review soon.