Summary
ProxySQL imposes client_encoding=UTF8 on backend PostgreSQL connections instead of inheriting the server/database default. Sessions through ProxySQL always report UTF8 even when the backend database's actual default is different.
Evidence (unconfounded)
Against a backend database with SQL_ASCII encoding (dbdeployer PG 17.10 default):
- Direct connection (psycopg3, no client pin):
SHOW client_encoding → SQL_ASCII (the true server default).
- Via ProxySQL (same user/db, no client pin):
SHOW client_encoding → UTF8.
Independently confirmed from a second angle: a client that requests client_encoding=LATIN1 through ProxySQL still observes UTF8.
Impact
- Protocol-visible divergence vs direct PostgreSQL: session defaults differ, which can change text decoding behavior for clients relying on server defaults (SQL_ASCII/LATIN1 databases).
- Any byte-transparency comparison (proxy vs direct) must pin
client_encoding explicitly on both sides to be apples-to-apples.
Where this is tracked in-tree
Found by the SP-2 differential harness (PR #5903) and recorded as a [[finding]] entry in test/pg-compat/xfail.toml (mode libpq). The harness neutralizes it by pinning client_encoding=UTF8 on every connection (test/pg-compat/harness/targets.py, all driver adapters) — documented, not hidden.
Expected
Either inherit the backend's default client_encoding for backend connections (forwarding the client's requested value where provided), or document UTF8-imposition as intended behavior — in which case the xfail.toml finding can be converted to a documented limitation.
Related: #5899, #5900 (same discovery-phase test effort).
Summary
ProxySQL imposes
client_encoding=UTF8on backend PostgreSQL connections instead of inheriting the server/database default. Sessions through ProxySQL always reportUTF8even when the backend database's actual default is different.Evidence (unconfounded)
Against a backend database with
SQL_ASCIIencoding (dbdeployer PG 17.10 default):SHOW client_encoding→SQL_ASCII(the true server default).SHOW client_encoding→UTF8.Independently confirmed from a second angle: a client that requests
client_encoding=LATIN1through ProxySQL still observesUTF8.Impact
client_encodingexplicitly on both sides to be apples-to-apples.Where this is tracked in-tree
Found by the SP-2 differential harness (PR #5903) and recorded as a
[[finding]]entry intest/pg-compat/xfail.toml(modelibpq). The harness neutralizes it by pinningclient_encoding=UTF8on every connection (test/pg-compat/harness/targets.py, all driver adapters) — documented, not hidden.Expected
Either inherit the backend's default
client_encodingfor backend connections (forwarding the client's requested value where provided), or document UTF8-imposition as intended behavior — in which case the xfail.toml finding can be converted to a documented limitation.Related: #5899, #5900 (same discovery-phase test effort).