lc_messages

Definition PG 18 manual

Sets the language in which messages are displayed. Acceptable values are system-dependent; see Section 23.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.

On some systems, this locale category does not exist. Setting this variable will still work, but there will be no effect. Also, there is a chance that no translated messages for the desired language exist. In that case you will continue to see the English messages.

Only superusers and users with the appropriate SET privilege can change this setting.

How it works

lc_messages sets the language in which messages are displayed. An empty string means use the operating system setting. The accepted locale names and available translations are operating-system and build dependent; an empty value inherits the server environment.

lc_messages is a SUPERUSER-context setting. Superuser or a role granted the appropriate SET privilege 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 lc_messages 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 lc_messages globally without a rollback plan and a client or operational compatibility test.

Workload guidance

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

OLTP: Treat lc_messages 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 lc_messages.