Pgbench: remove synchronous prepare

Incremental Update: Robert Haas Pushes Back on Need for New libpq Entrypoint

Robert Haas returns after pgconf.dev and directly challenges the fundamental premise of the patch — that a new libpq function is necessary.

The Core Objection

Haas clarifies that he was suggesting PQsendPrepare (the async, non-blocking variant of PQprepare), not PQsendQueryPrepared. He feels Bondar's earlier response conflated these two different functions. His argument:

1. The problem is that PQprepare() blocks → the obvious fix is to replace it with PQsendPrepare() (which is its direct non-blocking equivalent).
2. If using PQsendPrepare() causes pgbench to break (e.g., because the state machine can't handle a ParseComplete reply without tuple data), that indicates pgbench's state machine needs adjustment, not that libpq needs a new entrypoint.
3. The correct engineering response to "the non-blocking API doesn't fit our state machine" is to fix the state machine, not to paper over it with a new combined API call.

Technical Significance

This is a significant escalation of Haas's earlier naming concern into a fundamental architectural objection. Previously, the discussion assumed the new libpq function was necessary and debated its name. Now Haas is questioning whether the function should exist at all. His position is that the solution should be:

• Replace PQprepare() with PQsendPrepare() in pgbench
• Add a new pgbench state-machine state to consume the ParseComplete response
• Then proceed to PQsendQueryPrepared() for the Bind/Execute/Sync

This maps to Option 2 from the prior analysis (adding a new pgbench state to handle ParseComplete separately), which Bondar had rejected as invasive and architecturally wrong. Haas is now explicitly endorsing that approach as the correct one.

Implications for the Patch

The patch in its current form — adding a PQsendPBES-style combined function to libpq — is unlikely to be accepted without either:

• Convincing Haas that pgbench's state machine truly cannot be reasonably extended, or
• Reframing the new function as generally useful libpq infrastructure (the "gap in libpq's async API" argument from the prior analysis)

Bondar will need to either rework the patch to use PQsendPrepare + state machine changes in pgbench, or provide a much stronger justification for why a new libpq entrypoint is preferable to fixing pgbench internally.