ProxySQL's PostgreSQL module rejects `Bind` messages that request **mixed per-column result formats** (some result columns text, some binary) with:

[levikhulaifi]

Per the PostgreSQL protocol spec (Bind message format), the number of result-column format codes may be:

• 0 (all columns use default/text format), or
• 1 (applies to all columns), or
• equal to the number of result columns, each independently text or binary

This third case (mixed format codes) appears to be rejected outright instead of being forwarded to the backend, even though it's valid per protocol and PostgreSQL itself supports it natively.

ProxySQL version

3.1.11

OS version

Red Hat Enterprise Linux 9.4

Steps to reproduce

1. Set up ProxySQL 3.1.11 in front of a PostgreSQL backend.
2. Connect using a Go client with pgx v5 (default QueryExecModeCacheStatement, i.e. extended query protocol).
3. Run a plain SELECT against a table with mixed-type columns (e.g. int4, text, timestamptz).
4. Query fails with SQLSTATE 0A000 as shown above.

Connecting directly to the PostgreSQL backend (bypassing ProxySQL) with the same client/query works without error — confirming this is a ProxySQL-side limitation, not a client or backend issue.

Root cause (suspected)

pgx selects binary format per-column based on whether it has an efficient binary codec for that column's type (e.g. binary for int4/timestamptz, text for types it hasn't optimized). This produces a Bind message with differing format codes across columns — valid per protocol, but apparently unhandled by ProxySQL's Bind processing for PostgreSQL.

Additional finding

Enabling fast_forward on the relevant query rule makes the error disappear entirely, since fast_forward bypasses ProxySQL's PostgreSQL protocol parsing (including Bind message validation) and passes raw bytes directly to the backend. This strongly confirms the root cause is specifically in ProxySQL's Bind-message format-code validation logic in the normal (non-fast-forward) query processing path — not a backend or client-side issue.

This can also serve as a practical workaround for users who don't need query rules/rewriting/caching on the affected connection, at the cost of losing all ProxySQL query-level features for that traffic.

Additional context

Recent ProxySQL release notes mention a fix for "silent PostgreSQL data corruption on mixed Bind result formats" — this suggests the team is already aware mixed-format Bind handling was previously broken (silently corrupting data), and the current explicit-error behavior may be an intermediate safety fix rather than full support.

Could you confirm:

1. Is this a known/tracked limitation?
2. Is full support for mixed-format Bind planned for an upcoming release?

Full ProxySQL error log

No corresponding entry was found in /var/lib/proxysql/proxysql.log for this error — ProxySQL does not appear to log this specific rejection at default log verbosity. The error is only visible from the application/client side (see below).

Application-side error (client perspective)

{
  "level": "error",
  "message": "Error When Query",
  "function_name": "Provider.ListSomeTaskFunction",
  "log_type": "application",
  "metadata": {
    "default_value": "ERROR: per-column result formats are not supported: all result columns must request the same format code (SQLSTATE 0A000)"
  }
}