select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / CLIENT CONNECTION DEFAULTS

Sets how binary values are to be encoded in XML.

Type
enum
Context
user
Measured default
base64
Unit
Metadata snapshot
18
Allowed values
base64, hex

Definition PG 18 manual

Sets how binary values are to be encoded in XML. This applies for example when bytea values are converted to XML by the functions xmlelement or xmlforest. Possible values are base64 and hex, which are both defined in the XML Schema standard. The default is base64. For further information about XML-related functions, see Section 9.15.

The actual choice here is mostly a matter of taste, constrained only by possible restrictions in client applications. Both methods support all possible values, although the hex encoding will be somewhat larger than the base64 encoding.

Measured default history
Version intervalDefault
9.0 – 19base64
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

xmlbinary sets how binary values are to be encoded in XML. It affects bytea-to-XML conversion by XML construction functions; both base64 and hex preserve all bytes, but hex output is larger.

xmlbinary is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

Operational considerations

Changing xmlbinary in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.

Assuming a presentation setting changes stored values or server-side type semantics.

Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.

Changing xmlbinary globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: Pin xmlbinary for export, reporting, and reproducible analytical jobs; prefer explicit SQL formatting when a file or API has a durable schema.

OLTP: Treat xmlbinary as an application contract, not a performance knob. Standardize it per role or connection pool and keep wire formats explicit where clients parse text.

SMALL: Keep the upstream or locale-derived value unless a client requires another one. A smaller server gains no capacity from changing xmlbinary.

Version history 2
  1. PG 18 → 19changed
  2. PG 12 → 13changed

Related entries

Further reading

Definition snapshot: english-manuals:ba0c39d788d81e3a8e94e6832e6… · English manual source