Non-persistent queries fail spuriously if they reference custom types needing OID lookup

[patrickt]

I have found these related issues/pull requests

I could not find any existing examples.

Description

When passing a query with persistent: false that contains a reference to a custom Postgres data type, a spurious 26000 unnamed prepared statement does not exist error is encountered on the first try. Subsequent retries work.

Reproduction steps

I have reproduced this in https://github.com/patrickt/sqlx-bug and can confirm it returns a 26000 error in sqlx-0.9 but not in 0.8.

1. Check out the repo
2. DATABASE_URL=<your url here> cargo run
3. Observe the error code 26000 in the first statement
4. Change cargo.toml to pull in sqlx 0.8
5. Run again, observe that you get None rather than an error

SQLx version

0.9

Enabled SQLx features

postgres, runtime-tokio

Database server and version

Postgres 17

Operating system

macOS, Linux

Rust version

1.9.6

[abonander]

Hmm, I forgot that simple queries destroy the unnamed prepared statement anyway so my reasoning in https://github.com/transact-rs/sqlx/pull/4226/changes#diff-672b572067d63467cd3f15cabc51925570285f1d527a99ad24fa6a5334cc8f72R23-R27 was faulty to begin with.

There's not much reason not to use prepared statements, then, because we have to prepare the user's query twice either way when persistent = false. Although, in this case I think using raw queries is going to result in fewer round-trips to the server overall.

When persistent = true there's technically a crossover point where using prepared statements for these queries might be more efficient, but because we're caching this metadata anyways, the cost is going to be amortized either way.

The fix here is probably just to re-queue the Prepare. We technically shouldn't even need to wait for the statement metadata to be returned, though there's a possible race condition where something changed in the schema and the new metadata is different, but we're still operating with the old metadata. The safe bet is to just wait the extra round-trip to be sure of the correct metadata. The next time we execute the same statement, the type metadata should be in-cache so we should only have to do this once anyway.